Depart constraints implementation in autonomous vehicle routing

ABSTRACT

A method of controlling navigation of autonomous vehicles includes accessing map data descriptive of the identity and location of different travel ways within a surrounding environment of an autonomous vehicle and accessing constraint data descriptive of one or more geographic areas or geographic identifiers, within the map data, for which associated navigational constraints are defined. The constraint data includes a depart constraint that specifies an area that an autonomous vehicle may not enter but may exit if inside the area when the depart constraint is imposed, thereby preventing the autonomous vehicle from being trapped in a forbidden area even though the autonomous vehicle may safely complete its route. A travel route is determined for the autonomous vehicle based at least in part on the map data evaluated relative to the constraint data including the depart constraint, and motion of the autonomous vehicle is controlled based on the determined travel route.

CLAIM FOR PRIORITY

This application is a continuation of U.S. application Ser. No.16/538,275, filed Aug. 12, 2019, which claims the benefit of priority ofU.S. Provisional Patent Application Ser. No. 62/795,734, filed Jan. 23,2019, each of which is hereby incorporated by reference in its entirety.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is also related to U.S. patent application Ser. No.15/783,391, filed Oct. 13, 2017, which claims priority to U.S.Provisional Patent Application Ser. No. 62/503,798, filed May 9, 2017,and U.S. patent application Ser. No. 16/434,501, filed Jun. 7, 2019,which claims priority to U.S. Provisional Patent Application Ser. No.62/683,191, filed Jun. 11, 2018, all of which are hereby incorporated byreference for all purposes.

FIELD

This document pertains generally, but not by way of limitation, todevices, systems, and methods for operating an autonomous vehicle and,more particularly, to a routing system for autonomous vehicles thatimplements map constraints including depart constraints that specify anarea that an autonomous vehicle may not enter but may exit if inside thearea when the constraints are imposed.

BACKGROUND

An autonomous vehicle (AV) is a vehicle that is capable of sensing itsenvironment and operating some or all of the vehicle's controls based onthe sensed environment. An AV includes sensors that capture signalsdescribing the environment surrounding the vehicle and a navigationsystem that responds to the inputs to navigate the AV along a travelroute without human input. In particular, an AV can observe itssurrounding environment using a variety of sensors and can attempt tocomprehend the environment by performing various processing techniqueson data collected by the sensors. Given knowledge of its surroundingenvironment, the AV can determine an appropriate motion plan relative toa travel route through its surrounding environment.

The determination of a travel route along which an AV can navigate canbe based at least in part on map data. However, map data is not alwaysupdated to reflect changing availability of different travel ways. Inaddition, map data does not always include additional information aboutparticular events and/or conditions that may affect the navigationalavailability or preference of particular travel ways in a geographicarea.

DRAWINGS

In the drawings, which are not necessarily drawn to scale, like numeralsmay describe similar components in different views. Like numerals havingdifferent letter suffixes may represent different instances of similarcomponents. Some embodiments are illustrated by way of example, and notof limitation, in the figures of the accompanying drawings.

FIG. 1 depicts an example system for controlling the navigation of anautonomous vehicle according to example embodiments of the presentdisclosure;

FIG. 2 depicts an example system for communicating map data andconstraint data according to example embodiments of the presentdisclosure;

FIG. 3 depicts an example system for outputting map constraints to AVsaccording to example embodiments of the present disclosure;

FIG. 4 depicts a first example aspect of map data including travel wayportions according to example embodiments of the present disclosure;

FIG. 5 depicts second example aspect of map data including travel wayportions according to example embodiments of the present disclosure;

FIG. 6 depicts a third example aspect of map data including an examplegeographic location according to example embodiments of the presentdisclosure;

FIG. 7 depicts a fourth example aspect of map data including exampleconstraint data generated within the example geographic location of FIG.6 according to example embodiments of the present disclosure;

FIG. 8 depicts a fifth example aspect of map data including exampleconstraint data and a constraint data user interface according toexample embodiments of the present disclosure;

FIG. 9 depicts a first example user interface for applying constraintdata according to example embodiments of the present disclosure;

FIG. 10 depicts a second example user interface for applying constraintdata according to example embodiments of the present disclosure;

FIG. 11 depicts an example flow chart of a first example method ofcontrolling navigation of an autonomous vehicle according to exampleembodiments of the present disclosure;

FIG. 12 depicts an example flow chart of a method of determining atravel route for an autonomous vehicle according to example embodimentsof the present disclosure;

FIG. 13 depicts an example flow chart of a second example method ofcontrolling navigation of an autonomous vehicle according to exampleembodiment of the present disclosure;

FIG. 14 depicts an example system for providing up-to-date routeconstraint information to autonomous vehicles according to exampleembodiments of the present disclosure;

FIG. 15 depicts an example flow chart of a method of providingup-to-date route constraint information to autonomous vehicles accordingto example embodiments of the present disclosure;

FIG. 16A illustrates a lane marked by a depart constraint that may notbe entered from any lane which is not also marked with a departconstraint;

FIG. 16B illustrates a lane marked with a depart constraint that may beexited into lanes which may or may not be marked with a departconstraint;

FIG. 16C illustrates a lane marked with a depart constraint that isconsidered “high cost” relative to lanes not marked with a departconstraint;

FIG. 17A illustrates a set of road closures for a use case forconstraining out a non-immediate-safety-concern exclusion zone such as aparade route;

FIG. 17B illustrates the set of road closures of FIG. 17A whereforbidden routing constraints are applied to the road closure area;

FIG. 17C illustrates the set of road closures of FIG. 17A where a departconstraint is applied to road closure area instead of the forbiddenrouting constraint;

FIG. 18A illustrates a use case for escaping a localized safety hazardsuch as a burning bridge or sinkhole;

FIG. 18B illustrates the bridge of FIG. 18A with only forbidden routingconstraints applied in order to prevent new autonomous vehicles fromentering the bridge;

FIG. 18C illustrates the bridge of FIG. 18A with a depart constraintapplied to the bridge instead of the forbidden routing constraint;

FIG. 19 is a block diagram illustrating a computer system upon whichexample AV processing systems described herein may be implemented; and

FIG. 20 is a block diagram that illustrates a computer system upon whichexamples described herein may be implemented.

DESCRIPTION

Reference now will be made in detail to embodiments, one or moreexample(s) of which are illustrated in the drawings. Each example isprovided by way of explanation of the embodiments, not limitation of thepresent disclosure. It will be apparent to those skilled in the art thatvarious modifications and variations can be made to the embodimentswithout departing from the scope or spirit of the present disclosure.For instance, features illustrated or described as part of oneembodiment can be used with another embodiment to yield a still furtherembodiment. Thus, it is intended that aspects of the present disclosurecover such modifications and variations.

Example aspects of the present disclosure are directed to systems andmethods that control navigation of autonomous vehicles in accordancewith constraint data that identifies geographic areas for inclusionand/or exclusion as permissible areas for navigation by the autonomousvehicles. In particular, the systems and methods of the presentdisclosure can obtain constraint data descriptive of one or moregeographic identifiers (e.g., a polygon encompassing a geographic areaand/or a travel way identifier for at least a portion of one or morelanes within a particular travel way) and an application type associatedwith each geographic identifier. Constraint data can be received, forexample, from one or more remote computing devices configured to controloperation of a fleet of autonomous vehicles. Map data descriptive of theidentity and location of different travel ways within the surroundingenvironment of the autonomous vehicle can be accessed and evaluatedrelative to the constraint data in order to determine a travel route fornavigating the autonomous vehicle. Motion of the autonomous vehicle thencan be controlled based at least in part on the determined travel route.

The disclosed systems and methods can provide a dynamically configurablesystem for initializing and updating navigational constraints in orderto effectively manage autonomous vehicles during specific events (e.g.,a traffic accident, sporting event or street fair) and/or specific modesof operation (e.g., with or without human drivers, on-task or off-taskfrom performing a service). In addition, the use of hierarchicalconstraint data in the form of inclusion and/or exclusion polygons canadvantageously provide a flexible configuration for communicating andimplementing navigational constraints. As used herein, a constraint is acombination of an effect (what the constraint does) and a shape (wherethe constraint applies) which is the smallest atomic unit of thenavigation constraint system described herein.

More particularly, an autonomous vehicle (e.g., a ground-based vehicle,air-based vehicle, other vehicle type) can include a vehicle computingsystem that implements a variety of systems including the navigationconstraint system described herein. For instance, the vehicle computingsystem can include one or more sensors (e.g., image capture devices,RADAR devices, LIDAR devices, etc.), one or more computing devices fordetermining autonomous navigation, and one or more vehicle controlsystem(s) (e.g., for controlling braking, steering, powertrain). Thesensor(s) can be configured to obtain sensor data used to detectobject(s) including, for example, pedestrians that are located withinthe travel route (e.g., road) of the autonomous vehicle, travelling inan adjacent travel way (e.g., on a sidewalk, a running path), etc. Thesensor data can be indicative of locations associated with the object(s)within the surrounding environment of the autonomous vehicle at one ormore time(s). The sensor data can be provided to one or more computingdevices in the vehicle computing system.

In addition to the sensor data, the vehicle computing system canretrieve, access, or otherwise obtain map data that provides otherdetailed information about the surrounding environment of the autonomousvehicle. The map data can provide information regarding the identity andlocation of different travel ways (e.g., roads, road segments, lanes,lane segments, parking lanes, turning lanes, bicycle lanes, or otherportions of a particular travel way). In some examples, travel wayportions within accessed map data can include one or more descriptorsincluding, for example, a district identifier, a travel way portionidentifier, a start point for the travel way portion, an end point forthe travel way portion, a directionality (e.g., direction of trafficflow), and/or connectivity identifiers for other travel way portionsthat are predecessors and/or successors to a given travel way portion.Map data can also include the identity and location of different itemsthan travel ways, including but not limited to buildings,maintenance/service locations for the autonomous vehicles, parkingareas, traffic signs, traffic lights, traffic control devices, and/orany other map data that provides information that assists the vehiclecomputing system in comprehending and perceiving its surroundingenvironment and its relationship thereto.

The vehicle computing system can be configured to determine travelroutes for the autonomous vehicle based at least in part on the mapdata. In some examples, travel routes can be determined in accordancewith a navigational objective (e.g., traveling to a destination locationto perform a service such as a rideshare service, delivery service,courier service, etc.). Because autonomy systems can rely oncomputer-based determination of travel routes as opposed to humandetermination, it can sometimes be desirable to implement constraints onparticular travel areas that should be either included and/or excludedas permissible for navigation. For example, it may be desirable toexclude specific areas or specific travel ways within an area due toevents such as a traffic accident, street fair, construction, or thelike. Specific areas may be included as permissible for navigation byparticular autonomous vehicles that are assigned to perform services ina given area, thus affording efficient distribution of fleet resources.

In order to implement dynamic navigational constraints, constraint datacan provide information descriptive of one or more geographic areasand/or geographic identifiers within map data for which associatednavigational constraints are defined. In some examples, the navigationalconstraints can indicate those areas that should be included and/orexcluded from permissible areas for navigation by an autonomous vehicle.In some examples, existing constraint data can be provided at andobtained by one or more computing devices located on-board an autonomousvehicle. In some examples, the constraint data can be received from oneor more remote computing devices configured to control operation of afleet of autonomous vehicles. Constraint data can be the same for someor all vehicles in a fleet, or it can be customized per vehicledepending on factors such as the operation location, operating mode,etc. of each autonomous vehicle.

In sample embodiments, constraint data can be provided in a variety ofsuitable formats for evaluation by an autonomous vehicle relative toaccessible map data. In some implementations, constraint data can bedescriptive of one or more geographic identifiers and an applicationtype associated with each of the one or more geographic identifiers.Geographic identifiers can include, for example, one or more polygonsencompassing a geographic area, one or more travel way identifiersindicative of at least a portion of one or more lanes within aparticular travel way, or other identifiers. In some instances, theapplication type can indicate either that an associated geographic areacan be included in a permissible area for navigation by the autonomousvehicle or that it should be excluded from a permissible area fornavigation by the autonomous vehicle.

For example, the application type associated with each geographicidentifier can be selected from a predetermined group of applicationtypes (e.g., complete inclusion, partial inclusion, complete exclusion,partial exclusion, etc.). In another example, the application type canbe selected as a value from within a range of possible application typevalues (e.g., a number selected from within a range of 0-10 with 0 beingleast permissible or least preferred and 10 being most permissible ormost preferred). In another example, an application type can correspondto an associated cost factor for navigating in a particular geographicarea. One or more computing devices associated with an autonomousvehicle can evaluate the associated cost to determine a travel routethat minimizes a total cost based at least in part on the cost factorassociated with the application type as well as optional additional costfactors, cost functions or the like. Depending on the manner ofapplication type, travel routes can be determined that not only canexclude particular areas from navigation but that additionally oralternatively can reduce traffic in particular areas based at least inpart on evaluation of the constraint data.

The use of polygonal constraint data is an example approach thatprovides a highly flexible manner of defining constraints. Instead ofhaving to list out numerous different travel way portion identifiers forinclusion or exclusion in a given area, polygons can be created to morebroadly define geographic areas for inclusion and/or exclusion. Thenumber of vertices, number of edges, and/or overall shape of a polygonencompassing a particular geographic area can be customized in numerousways to accomplish specific navigational constraint objectives. Inaddition, polygons can be assigned to a constraint set characterized bya default state (e.g., inclusion for permitted travel, exclusion forforbidden travel). By using polygonal constraint data, multiple travelway portions can be determined as included and/or excluded based on thelocation and application type associated with each polygon and thedefault state for the constraint set containing each polygon. Forinstance, permitted travel way portions can be determined as thosetravel way portions that are described by a constraint set having adefault “permit” state and/or that are completely enclosed by a completeinclusion polygon and/or that are completely enclosed or partiallytouched by a partial inclusion polygon. Forbidden travel way portionscan be determined as those travel way portions that are described by aconstraint set having a default “forbid” state and/or that arecompletely enclosed by a complete exclusion polygon and/or that arecompletely enclosed or partially touched by a partial exclusion polygon.

In some examples, constraint data can be determined, evaluated orotherwise considered by a vehicle computing system based on a currentmode of operation for an autonomous vehicle. Different modes ofoperation can include, for example, a fully autonomous mode in which theautonomous vehicle operates without a human driver present in thevehicle, an autonomous mode in which the autonomous vehicle operateswith a human driver in the vehicle, or other modes. In someimplementations, constraint data can include a priori map constraintsidentifying that an autonomous vehicle should be excluded from making aleft hand turn in particular turn lanes of a given travel way or travelway portion when a vehicle is operating in a particular mode. Differentmodes of operation can additionally or alternatively include, forexample, whether a vehicle is currently engaged or not engaged inperforming a service. For instance, some vehicles may currently havepassengers on board that are being driven from one location to another,while other vehicles may be engaged in controlled navigation but are notcurrently engaged in a particular operational task. Constraint data mayselectively include on-task autonomous vehicles to navigate in aparticular area while excluding autonomous vehicles that are off-task.

Composite constraint data can be generated by modifying existingconstraint data accessed by an autonomous vehicle based at least in parton one or more constraint files received, for example, from one or moreremote computing devices remote from the autonomous vehicle. The one ormore constraint files can be descriptive of additional navigationalconstraints for one or more geographic areas and/or geographicidentifiers. For example, each constraint file may include a constraintset including zero or more geographic identifiers (e.g., polygons havingboundaries defined relative to a geographic area and having anassociated application type) as well as a default state indicatingwhether to by default permit or forbid areas described by the constraintfile. The application type associated with each geographic identifier(e.g., polygon) can describe how to evaluate the geographic identifierrelative to map data. For example, an inclusion type can indicate thattravel way portions within map data that are enclosed or touched by aninclusion polygon should be permitted. An exclusion type can indicatethat travel way portions within map data that are enclosed or touched byan exclusion polygon should be forbidden. A complete type can indicatethat travel way portions within map data that are completely enclosed bya polygon should be permitted or forbidden. A partial type can indicatethat travel way portions within map data that are completely enclosed oreven just partially touched by a polygon should be permitted orforbidden. Also, as described more fully below, a depart type constraintmay be applied to indicate that an area may not be entered by anautonomous vehicle but that an autonomous vehicle may depart the area ifinside the area when the constraints are imposed.

After an autonomous vehicle obtains constraint data, one or morecomputing systems located on-board or off-board the autonomous vehiclecan determine a travel route for navigating the autonomous vehicle. Thetravel route can be determined at least in part from map data that isevaluated relative to the composite constraint data. For example, themap data can be evaluated in association with the composite constraintdata to determine which travel way portions are permitted and whichtravel way portions are forbidden. A travel route can be determined thatnever incorporates a forbidden travel way portion. The determined travelroute can include, for example, a sequence of multiple travel wayportions along which an autonomous vehicle can navigate, for example, toaccomplish a predetermined navigational objective. Each travel wayportion within a determined travel route can be defined by one or moreof a travel way identifier, a start point, an end point, adirectionality, and/or connectivity identifiers for predecessor and/orsuccessor travel way portions.

Once a travel route is determined, a vehicle computing system candetermine a motion plan to control motion of the autonomous vehiclealong the determined travel route. The motion plan can be further basedon any objects proximate to the autonomous vehicle (e.g., pedestrians,other vehicles, traffic control devices, etc.) that are detected by thevehicle's sensors, image capture devices, or other data acquisitionsystem components. For instance, the vehicle computing system can be acomputing system that includes various sub-systems that cooperate toperceive the surrounding environment of the autonomous vehicle anddetermine a motion plan for controlling the motion of the autonomousvehicle. For instance, the vehicle computing system can include aperception system, a prediction system, and a motion planning system.

In other implementations of the disclosed systems and methods, one ormore remote computing devices can be configured to implement systems andmethod of controlling operation of one or more autonomous vehicles. Insome examples, such remote computing device(s) can be included as partof a central control system that is in wireless communication with aplurality of autonomous vehicles, such as a fleet of autonomous vehiclesproviding one or more services (rideshare service, delivery service,courier service, etc.). The one or more remote computing devices cancreate a constraint set with zero or more geographic identifiers and adefault state (e.g., permit or forbid or depart) that indicates whetherto by default permit or forbid areas or instruct the autonomous vehicleto immediately depart the area described by the constraint file. The oneor more remote computing devices can identify an event at somegeographic location that will impact navigation at such location (e.g.,a street fair, sporting event, traffic accident, bridge closure, parade,etc.). The one or more remote computing devices can then determineconstraint data associated with the identified event. For example,constraint data can be determined including one or more geographicidentifiers such as polygons having boundaries defined relative to ageographic area including the location of the event identified. In someexamples, at least one such polygon can encompass a geographic areaincluding the location of the identified event. The one or moregeographic identifiers (e.g., polygons) can include an associatedapplication type (e.g., complete inclusion, partial inclusion, completeexclusion, partial exclusion). The one or more remote computing devicesthen can assign the one or more geographic identifiers to the constraintset and transmit the constraint data to one or more autonomous vehiclesover a network.

Identification of events, for which the disclosed constraint data can bedetermined can come from data descriptive of an upcoming event (e.g.,sporting event, bridge closure, parade, or the like) and/or historicaldata (e.g., by approximating navigational limitations based on pastevents in a particular geographic region at a certain time and/or date).The one or more remote computing devices can utilize various databasesto predict, approximate, and/or determine the events and/or geographiclocations of anticipated navigational limitations. For example, fordifferent geographic regions, event information (e.g., location, time,and/or date of the event, or the like) can be stored in an eventdatabase. Event information can be indicative of whether traffic can behigher or lower at a certain time period (e.g., a time period before theevent begins versus a time period when the event is ongoing). In anotherexample, event information can come from calendar databases thatindicate important dates (e.g., holidays, first days of school for acity, voting day, or the like). Other examples of outside sources orother stored data (e.g., predicted future, current and/or historicevents, conditions, or the like) include weather conditions, newsinformation (e.g., fires, emergency situations, or the like), socialinformation (e.g., via social networking websites), traffic conditions,flight information from airports and/or airlines, or the like, or otherinformation that can assist in determining event information, trafficpatterns or other data contributing to potential navigationalconstraints.

The systems, methods, and vehicles described herein may provide a numberof technical effects and benefits. For instance, the vehicle computingsystem can locally (e.g., on-board the vehicle) obtain constraint data,evaluate map data relative to the constraint data, and determine atravel route for navigating the autonomous vehicle in compliance withthe constraint data. By performing such operations on-board theautonomous vehicle, the vehicle computing system can avoid certainlatency issues that arise by reliance on a remote computing system foroff-board operations. For example, the vehicle computing system can beconfigured to initialize and update its travel route(s) based onobtained constraint data and accessible map data as opposed to waitingfor determined travel routes to be approved or disapproved by a centralcommand or other remote computing device/system. As such, map data canbe evaluated relative to constraint data and travel routes can bedetermined with increased computational efficiency.

The systems, methods, and vehicles described herein have an additionaltechnical effect and benefit of providing a flexible and customizableapproach to defining included and/or excluded geographic areas fornavigation by an autonomous vehicle. By communicating constraints to anautonomous vehicle from one or more remote computing devices, a fleetoperator associated with the remote computing devices is affordedflexibility in controlling navigation. Fleet operators have theflexibility of sending instructions to an entire fleet of vehiclesoperating in a given geographic area, to just one autonomous vehicle, orto a subset of vehicles. Fleet operators can provide inclusion areasand/or exclusion areas to an autonomous vehicle in real time or nearreal time to account for numerous dynamically changing events (e.g., atraffic accident, construction, street fair, parade, bridge closure,etc.) and/or specific modes of operation (e.g., operation of theautonomous vehicle with or without human drivers). This dynamic approachhelps autonomous vehicles adjust their travel routes in real time ornear real time without having to regenerate limitations within map dataor require autonomous vehicles to return to a central command center toupload new maps.

In some implementations, polygonal constraint data can provide a highlyflexible manner of defining constraints whereby geographic areas forinclusion and/or exclusion can be more broadly defined as opposed tolisting out numerous specific travel way portion identifiers. Inclusionareas and/or exclusion areas can be added and/or removed from constraintdata one at a time in order to provide flexible updates to one or moreautonomous vehicles, thus reducing the amount of data communicatedremotely to an autonomous vehicle. In addition, constraint data can bedefined that is customized based on location in order to account fortravel way design, operational parameters, events, etc. that aredifferent from city to city, country to country or the like.

The systems, methods, and vehicles described herein have an additionaltechnical effect and benefit of providing more efficient navigationwhile simultaneously enhancing the safety and security of autonomousvehicles, passengers and/or cargo. By providing a mechanism to obtainconstraint data, autonomous vehicles can benefit from the knowledge ofwhen and where potential problem areas may exist for travel routes. Avehicle computing system can determine optimized travel routes or updatetravel routes in an enhanced manner by evaluating map data relative tocurrent constraint data in order to avoid exclusion areas. By planningahead to avoid such areas, the potential for navigational back-trackingis reduced. In addition, by avoiding exclusion areas that are identifiedbecause of certain events (e.g., traffic accidents, protestordemonstrations, parades, bridge closures, etc.), and by enabling theautonomous vehicle to drive out of a depart constraint area, the safetyof vehicles, passengers, and/or cargo can be increased.

The systems, methods, and vehicles described herein also provide animprovement to vehicle computing technology, such as autonomous vehiclecomputing technology. For instance, aspects of the present disclosureenable a vehicle computing system to more efficiently and accuratelycontrol the vehicle's motion. By planning which travel way portions(e.g., turn lanes, narrow lanes, lanes with blind spots, etc.) that anautonomous vehicle should use or avoid based in part on obtainedconstraint data, motion plans can be determined in advance along anideal travel route. Improved autonomy and effective determination of avehicle travel route and motion plan can be a primary factor inachieving enhanced overall operation of an autonomous vehicle.

During normal fleet operations of autonomous vehicles, it may becomenecessary to react to changes to the operating environment that restrictthe valid operating environment for the autonomous vehicles. Thesechanges are often transient in nature and thus are not desirable to beincluded in the map. Examples range from construction zones, tosinkholes, to parades. The primary tools for addressing such changes isto employ Forbid Routing (FBR) (an effect that completely prevents(excludes) routing in the affected area) and High Cost/Avoid (HCA) (aneffect that causes the affected area to be “more expensive” to traversewhereby the affected routes would be less likely to be traversed in theaffected area) constraints. Other constraints may include forced manualfrom Auto/Routable Non-Auto (RNA) where RNA lanes can be used to routebut only for manual driving. By using the navigation constraints systemdescribed herein, operators may annotate the map dynamically and alterthe routing behavior of one or more autonomous vehicles. By way ofexample only, the routing systems described in U.S. patent applicationSer. Nos. 16/173,654 and 16/173,633 are exemplary and are incorporatedherein by reference.

A Navigation Constraints System (NCS) as described herein is the primarytool used in order to decide where in a lane graph it is permissible fora route to traverse, as well as what mode the AV should be in while ittraverses the route. The NCS can be utilized by operators in order toaffect the behavior of an autonomous vehicle fleet dynamically, but italso may be used to block off certain portions of the map of anautonomous vehicle that may not be used due to organizational policiesor autonomy capabilities.

However, there are limitations to these NCS tools in certain operatingenvironments. For example, High Cost/Avoid is merely a suggestion. Itwill, on average, cause the autonomous vehicle(s) to avoid an area, butit will not prevent them from entering it. On the other hand, ForbidRouting is an absolute. Autonomous vehicles will never traverse lanesmarked as FBR, for any reason. This becomes especially problematic in anautonomous vehicle setting where there is no human operator as it ispossible that constraints may be applied that will strand the autonomousvehicle by constraining travel in the area the autonomous vehicle iscurrently occupying. In this situation, the only safe thing theautonomous vehicle can do is to perform a safe stop, because it mustassume that the FBR constraint was applied for a reason, and it is nolonger safe to continue traversing that area.

While performing a safe stop may be the appropriate action in certainemergency situations, it is quite possible that the autonomous vehiclecould safely maneuver out of a constrained area without jeopardizing thesafety of the occupants of the autonomous vehicle. For example, when asafety driver is in the autonomous vehicle, the autonomous vehicle mayrequire the human operator to actually push a button to apply newconstraints and ask the human operator not to do this until they are notexecuting a mission. This means that before they accept the constraints,the human is trusted to handle any unsafe conditions which the newconstraints may have been trying to communicate and make the autonomousvehicle avoid. After the constraints are accepted, the human safetyoperator may simply drive the vehicle back into the “allowed” operatingarea if it becomes stranded due to the new constraints. However, in theabsence of the human driver, the autonomous vehicle would otherwise bestranded in the forbidden area and system operators must try to avoidpushing constraints they know will strand an autonomous vehicle andpassengers. This situation also presents a safety concern because itdelays communicating possibly safety-critical information to the rest ofthe autonomous vehicle fleet in an emergency situation.

The inventors have recognized that there are many situations where anFBR constraint is applied but the operators do not actually mean “do notenter this area and the only safe thing to do in this area is stopmoving.” What they actually mean is “do not enter this area and exit itif you are currently in it.” For example, in the case of a plannedparade route, it is undesirable for an autonomous vehicle to enter theparade route after the constraints annotating the parade route have beendeployed. On the other hand, it is perfectly appropriate that anyautonomous vehicle currently traversing the parade route be allowed tocontinue moving, so long as the autonomous vehicle exits the area of theparade route as expediently as possible as there is no immediate safetyrisk. Constraints for implementing such a feature are described hereinas depart constraints that are associated with an area to indicate thatthe area can be traversed by autonomous vehicles already inside the areawhen the constraints are imposed, that the area can be exited byautonomous vehicles already inside the area, that autonomous vehiclesoutside the area cannot enter the area after the depart constraints areimposed, and that traversal should bias towards exiting the area asexpediently as practical.

Sample embodiments described herein include a computer-implementedmethod of controlling navigation of an autonomous vehicle to imposeconstraints including such depart constraints. The method includesaccessing map data descriptive of the identity and location of differenttravel ways within a surrounding environment of the autonomous vehicleand constraint data descriptive of one or more geographic areas orgeographic identifiers, within the map data, for which associatednavigational constraints are defined. In the sample embodiments, theconstraint data includes a depart constraint that specifies an area thatan autonomous vehicle may not enter but may exit if inside the area whenthe depart constraint is imposed. One or more processors determine atravel route for navigating the autonomous vehicle based at least inpart from the map data evaluated relative to the constraint dataincluding the depart constraint and controls motion of the autonomousvehicle based at least in part on the determined travel route.

The method includes imposing the depart constraint on a lane in the mapdata, the depart constraint indicating that an autonomous vehicle in thelane may continue to traverse the lane while inside the lane and mayexit the lane but that an autonomous vehicle outside of the lane may notenter the lane. The lane is given a high traversal cost to bias anautonomous vehicle in the lane towards exiting the lane.

The method further includes receiving one or more constraint filesincluding the constraint data from one or more remote computing devicesconfigured to control operation of a fleet of autonomous vehicles. Insample embodiments, each of the one or more constraint files includesone or more polygons, each polygon having a boundary defined relative toa geographic area and an associated application type. In the sampleembodiments, determining the travel route for navigating the autonomousvehicle may further include determining, by the one or more processors,permitted travel way portions, the permitted travel way portions beingdescribed by constraint data as (i) having a default permit state, (ii)being completely enclosed by a complete inclusion polygon, or (iii)being completely enclosed or partially touched by a partial inclusionpolygon and determining, by the one or more processors, forbidden travelway portions, the forbidden travel way portions being described by theconstraint data as (i) having a default forbid state, (ii) beingcompletely enclosed by a complete exclusion polygon, or (iii) beingcompletely enclosed or partially touched by a partial exclusion polygon.The one or more processors evaluate the map data to account for thepermitted travel way portions and the forbidden travel way portions.

In further sample embodiments, the one or more remote computing devicesgenerate a map constraint interface enabling a fleet operator to updatemap constraints for autonomous vehicles (AVs), the map constraintinterface enabling the fleet operator to configure a set of constraintlayers of one or more autonomy maps utilized by the AVs for navigation,where each constraint layer in the set of constraint layers comprises atoggle feature that enables the fleet operator to activate anddeactivate the constraint layer. A set of inputs configuring the set ofconstraint layers of the one or more autonomy maps is received via themap constraint interface and a set of map constraints corresponding tothe configured set of constraint layers is compiled into a documentcontainer that is output via a communication interface over one or morenetworks to a subset of the AVs to enable the subset of AVs to integratethe set of map constraints with the one or more autonomy maps.

The disclosure described herein further describes a correspondingcomputing system and computer-readable media for controlling navigationof an autonomous vehicle and an autonomous vehicle including such acomputing system.

Further sample embodiments include a computing device for controllingone or more autonomous vehicles. The computing device receives from oneor more networks traffic flow constraint information from at least oneof a central planning resource or a traffic monitoring resource. Basedon the traffic flow constraint information, autonomy map constraints forautonomous vehicles operating in a given region are updated. Theautonomy map includes constraint data defining constraints descriptiveof one or more geographic areas or geographic identifiers for whichassociated navigational constraints are defined, and the constraint dataincludes a depart constraint that specifies an area that an autonomousvehicle may not enter but may exit if inside the area when the departconstraint is imposed. The data indicating the autonomy map constraintsis transmitted over the one or more networks to the one or moreautonomous vehicles. In sample embodiments, the data indicating theautonomy map constraints is selectively transmitted to the one or moreautonomous vehicles based on the one or more autonomous vehicles eachbeing on a current route converging towards or intersecting with a roadsegment closure defined by the autonomy map constraints.

In the sample embodiments, a constraint file comprising the constraintdata is generated and transmitted to the one or more autonomousvehicles. The traffic flow constraint information identifies a plannedevent that corresponds to a road segment closure within the givenregion. The planned event may correspond to at least one of roadconstruction or utility servicing and may comprise at least one of aprotest, a parade, a sporting event, and a festival. The traffic flowconstraint information also may be received from a live, crowded-sourcedtraffic resource.

The disclosure described herein further describes corresponding methodsand computer-readable media for controlling navigation of an autonomousvehicle.

With reference now to the Figures, example embodiments of the presentdisclosure will be discussed in further detail. FIG. 1 depicts anexample vehicle computing system 100 of an autonomous vehicle 102according to example embodiments of the present disclosure. Theautonomous vehicle 102 incorporating the vehicle computing system 100can be a ground-based autonomous vehicle (e.g., car, truck, bus), anair-based autonomous vehicle (e.g., airplane, drone, helicopter, orother aircraft), or other type of vehicles (e.g., watercraft). Theautonomous vehicle 102 can be configured to drive, navigate, operate,etc. with minimal and/or no interaction from a human driver. Forexample, the autonomous vehicle 102 can be configured to operate in oneor more mode(s) such as, for example, a fully autonomous operationalmode and/or a semi-autonomous operational mode. A fully autonomous(e.g., self-driving) operational mode can be one in which the autonomousvehicle 102 can provide driving and navigational operation with nointeraction from a human driver. A semi-autonomous operational mode canbe one in which the autonomous vehicle 102 can operate with someinteraction from a human driver present in the vehicle. In someimplementations, the autonomous vehicle 102 can be associated with anentity (e.g., a service provider) that provides one or more vehicleservice(s) to a plurality of users via a fleet of vehicles thatincludes, for example, the autonomous vehicle 102. The vehicleservice(s) can include transportation services (e.g., rideshareservices), courier services, delivery services, and/or other types ofservices. The vehicle service(s) can transport and/or deliver passengersas well as items such as but not limited to food, animals, freight,purchased goods, etc.

As further illustrated in FIG. 1, the vehicle computing system 100 caninclude one or more sensors 104, one or more computing devices 106 andone or more vehicle controls 108. One or more of these systems can beconfigured to communicate with one another via a communication channel.The communication channel can include one or more data buses (e.g.,controller area network (CAN)), diagnostics connector (e.g., OBD-11),and/or a combination of wired and/or wireless communication links. Anyon-board systems can send and/or receive data, messages, signals, etc.amongst one another via the communication channel. The one or morecomputing devices 106 can include a perception system 110, a predictionsystem 112, and a motion planning system 114 that cooperate to perceivethe surrounding environment of the autonomous vehicle 102 and todetermine a motion plan for controlling the motion of the autonomousvehicle 102 accordingly.

In particular, in some implementations, the perception system 110 canreceive sensor data from the one or more sensors 104 that are coupled toor otherwise included within the autonomous vehicle 102. As examples,the one or more sensors 104 can include a Light Detection and Ranging(LIDAR) system, a Radio Detection and Ranging (RADAR) system, one ormore cameras (e.g., visible spectrum cameras, infrared cameras, etc.),and/or other sensors. The sensor data can include information thatdescribes the location of objects within the surrounding environment ofthe autonomous vehicle 102 (e.g., at one or more times).

As one example, for a LIDAR system, the sensor data from sensor(s) 104can include the location (e.g., in three-dimensional space relative tothe LIDAR system) of a number of points that correspond to objects thathave reflected a ranging laser. For example, a LIDAR system can measuredistances by measuring the Time of Flight (TOF) that it takes a shortlaser pulse to travel from the sensor to an object and back, calculatingthe distance from the known speed of light.

As another example, for a RADAR system, the sensor data from sensor(s)104 can include the location (e.g., in three-dimensional space relativeto the RADAR system) of a number of points that correspond to objectsthat have reflected a ranging radio wave. For example, radio waves(pulsed or continuous) transmitted by the RADAR system can reflect offan object and return to a receiver of the RADAR system, givinginformation about the object's location and speed. Thus, a RADAR systemcan provide useful information about the current speed of an object.

As yet another example, for one or more cameras, various processingtechniques (e.g., range imaging techniques such as, for example,structure from motion, structured light, stereo triangulation, and/orother techniques) can be performed to identify the location (e.g., inthree-dimensional space relative to the one or more cameras) of a numberof points that correspond to objects that are depicted in imagerycaptured by the one or more cameras. Other sensor systems can identifythe location of points that correspond to objects as well.

Thus, the one or more sensors 104 can be used to collect sensor datathat includes information that describes the location (e.g., inthree-dimensional space relative to the autonomous vehicle 102) ofpoints that correspond to objects within the surrounding environment ofthe autonomous vehicle 102.

In addition to the sensor data, the computing device(s) 106 can retrieveor otherwise obtain map data 118 that provides detailed informationabout the surrounding environment of the autonomous vehicle 102. The mapdata can provide information regarding the identity and location ofdifferent travel ways (e.g., roads, road segments, lanes, lane segments,parking lanes, turning lanes, bicycle lanes, or other portions of aparticular travel way). In some examples, travel way portions withinaccessed map data can include one or more descriptors including, forexample, a travel way portion identifier, a start point for the travelway portion, an end point for the travel way portion, a directionality(e.g., direction of traffic flow), and/or connectivity identifiers forother travel way portions that are predecessors and/or successors to agiven travel way portion. Map data can also include the identity andlocation of different items than travel ways, including but not limitedto buildings, maintenance/service locations for the autonomous vehicles,parking areas, traffic signs, traffic lights, traffic control devices,and/or any other map data that provides information that assists thecomputing system in comprehending and perceiving its surroundingenvironment and its relationship thereto. An example depiction of mapdata 118 for given travel way portions is provided in FIGS. 4-5 and willbe discussed below.

The computing device(s) 106 also can retrieve or otherwise obtainconstraint data 120 that provides information descriptive of one or moregeographic areas and/or geographic identifiers within a map for whichassociated navigational constraints are defined. In some examples,constraint data 120 can identify geographic areas within map data 118that should be included and/or excluded from permissible areas (orpreferred and/or not preferred) for navigation by autonomous vehicle102. For instance, constraint data 120 can include instructions forexcluding or reducing travel in specific areas or specific travel wayswithin an area due to events such as a traffic accident, street fair,construction, parade, bridge closure, or the like. Constraint data 120can alternatively include instructions for including specific areas orspecific travel ways as permissible for navigation by particularautonomous vehicles assigned to perform services in a given area, thusaffording efficient distribution of fleet resources. Additionaldescription regarding more particular types and examples of constraintdata 120 is provided relative to FIGS. 6-10.

The computing device(s) 106 can also include a route determiner 122configured to determine travel routes for the autonomous vehicle 102based at least in part on the map data 118 evaluated relative to theconstraint data 120. In some examples, travel routes can be determinedby route determiner 122 in accordance with a navigational objective(e.g., traveling to a destination location to perform a service such asrideshare service, delivery service, courier service, etc.). Routedeterminer 122 can evaluate the map data 118 in association with theconstraint data 120 to determine which travel way portions are includedand/or which travel way portions are excluded. The determined travelroute can include, for example, a sequence of multiple permitted travelway portions along which an autonomous vehicle can navigate, forexample, to accomplish a predetermined navigational objective. Eachtravel way portion within a determined travel route can be defined byone or more of a travel way identifier, a start point, an end point,directionality, and/or connectivity identifiers for predecessor and/orsuccessor travel way portions.

The perception system 110 can identify one or more objects that areproximate to the autonomous vehicle 102 based on sensor data receivedfrom the one or more sensors 104 and/or the map data 118. In particular,in some implementations, the perception system 110 can determine, foreach object, state data that describes a current state of such object.As examples, the state data for each object can describe an estimate ofthe object's: current location (also referred to as position); currentspeed (also referred to as velocity); current acceleration; currentheading; current orientation; size/footprint (e.g., as represented by abounding shape such as a bounding polygon or polyhedron); class (e.g.,vehicle versus pedestrian versus bicycle versus other); yaw rate; and/orother state information. In some implementations, the perception system110 can determine state data for each object over a number ofiterations. In particular, the perception system 110 can update thestate data for each object at each iteration. Thus, the perceptionsystem 110 can detect and track objects (e.g., vehicles) that areproximate to the autonomous vehicle 102 over time.

The prediction system 112 can receive the state data from the perceptionsystem 110 and predict one or more future locations for each objectbased on such state data. For example, the prediction system 112 canpredict where each object will be located within the next 5 seconds, 10seconds, 20 seconds, etc. As one example, an object can be predicted toadhere to its current trajectory according to its current speed. Asanother example, other, more sophisticated prediction techniques ormodeling can be used.

The motion planning system 114 can determine a motion plan for theautonomous vehicle 102 based at least in part on the travel routedetermined by route determiner 122 and/or the predicted one or morefuture locations for the object and/or the state data for the objectprovided by the perception system 110. Stated differently, giveninformation about the current locations of objects and/or predictedfuture locations of proximate objects, as well as a predetermined travelroute, the motion planning system 114 can determine a motion plan forthe autonomous vehicle 102 that best navigates the autonomous vehicle102 along the determined travel route relative to the objects at suchlocations.

As one example, in some implementations, the motion planning system 114can determine a cost function for each of one or more candidate motionplans for the autonomous vehicle 102 based at least in part on thecurrent locations and/or predicted future locations of the objects. Forexample, the cost function can describe a cost (e.g., over time) ofadhering to a particular candidate motion plan. For example, the costdescribed by a cost function can increase when the autonomous vehicle102 strikes another object and/or deviates from a preferred pathway(e.g., a predetermined travel route).

Thus, given information about the current locations and/or predictedfuture locations of objects, the motion planning system 114 candetermine a cost of adhering to a particular candidate pathway. Themotion planning system 114 can select or determine a motion plan for theautonomous vehicle 102 based at least in part on the cost function(s).For example, the motion plan that minimizes the cost function can beselected or otherwise determined. The motion planning system 114 canprovide the selected motion plan to a vehicle controller 116 thatcontrols one or more vehicle controls 108 (e.g., actuators or otherdevices that control gas flow, steering, braking, etc.) to execute theselected motion plan.

Each of the perception system 110, the prediction system 112, the motionplanning system 114, the vehicle controller 116, and the routedeterminer 122 can include computer logic utilized to provide desiredfunctionality. In some implementations, each of the perception system110, the prediction system 112, the motion planning system 114, thevehicle controller 116, and the route determiner 122 can be implementedin hardware, firmware, and/or software controlling a general-purposeprocessor. For example, in some implementations, each of the perceptionsystem 110, the prediction system 112, the motion planning system 114,the vehicle controller 116 and the route determiner 122 includes programfiles stored on a storage device, loaded into a memory and executed byone or more processors. In other implementations, each of the perceptionsystem 110, the prediction system 112, the motion planning system 114,the vehicle controller 116, and the route determiner 122 includes one ormore sets of computer-executable instructions that are stored in atangible computer-readable storage medium such as RAM hard disk oroptical or magnetic media, as is further described in FIG. 2.

FIG. 2 depicts a block diagram of an example computing system 200according to example embodiments of the present disclosure. Inparticular, FIG. 2 illustrates an example implementation of the presentdisclosure in which one or more remote computing devices 150 arecommunicatively coupled with one or more vehicle computing devices 106over a network 180. Each vehicle computing device 106 can be part of avehicle computing system 100 associated with a particular autonomousvehicle 102. It should be appreciated that FIG. 2 illustrates only oneexample computing system 200 that can be used to implement the presentdisclosure. Other computing systems can be used as well.

Each vehicle computing device 106 can include one or more processors 138and a memory 140. The one or more processors 138 can be any suitableprocessing device (e.g., a processor core, a microprocessor, an ASIC, aFPGA, a controller, a microcontroller, etc.) and can be one processor ora plurality of processors that are operatively connected. The memory 140can include one or more non-transitory computer-readable storagemediums, such as RAM, ROM, EEPROM, EPROM, flash memory devices, magneticdisks, etc., and combinations thereof. The memory 140 can store data 142and instructions 144 which are executed by the processor 138 to causethe vehicle computing device 106 to perform operations. Data 142 caninclude map data 118 and constraint data 120.

The vehicle computing device(s) 106 can obtain map data 118 and/orconstraint data 120 via interaction with the remote computing device(s)150 that are communicatively coupled over the network 180. The remotecomputing device(s) 150 can be separate from the vehicle computingdevice(s) 106 and provided in a location remote from the vehiclecomputing device(s) 106, for instance, in a central control systemassociated with a service provider, owner, and/or fleet operatorcontrolling a fleet of autonomous vehicles 102.

The remote computing device(s) 150 can include one or more processors152 and a memory 154. The one or more processors 152 can be any suitableprocessing device (e.g., a processor core, a microprocessor, an ASIC, aFPGA, a controller, a microcontroller, etc.) and can be one processor ora plurality of processors that are operatively connected. The memory 154can include one or more non-transitory computer-readable storagemediums, such as RAM, ROM, EEPROM, EPROM, flash memory devices, magneticdisks, etc., and combinations thereof. The memory 154 can store data 156and instructions 158 which are executed by the processor 152 to causethe remote computing device(s) 150 to perform operations. The data 156can include map data 118 and constraint data 120 that is relayed overnetwork 180 to one or more vehicle computing devices 106 associated withrespective autonomous vehicles 102.

The network 180 can be any type of communications network, such as alocal area network (e.g., intranet), wide area network (e.g., Internet),or some combination thereof and can include any number of wired orwireless links. In general, communication over the network 180 can becarried via any type of wired and/or wireless connection, using a widevariety of communication protocols (e.g., TCP/IP, HTTP, SMTP, FTP),encodings or formats (e.g., HTML, XML), and/or protection schemes (e.g.,VPN, secure HTTP, SSL). In some examples, vehicle computing device(s)106 and/or remote computing device(s) 150 can further include one ormore communication interfaces 146, 160, including any suitablecomponents (transmitters, receivers, ports, controllers, antennas, etc.)for interfacing with network 180 or one or more other networks.

FIG. 3 depicts an example computer system for outputting map constraintsto AVs, according to example embodiments of the present disclosure. Asillustrated, computing system 150 may be adapted to include AVcommunication interface 160 that communicates with a fleet of AVs 102via one or more networks 180. The computing system 150 further includesa fleet operator interface 300 connected over a network 302 with acomputing device 304 operable by fleet operators 306. The computingdevice 304 can display a map constraint interface 310 enabling the fleetoperators 306 to configure map constraints to be merged into theautonomy maps utilized by the AVs 102. The computing system 150 canfurther include a database 320 storing autonomy map documents 322 andaudit logs 324, as described herein. The computing system 150 canfurther include a map constraint compiler 330, a compression module 340,and a constraint deployment module 350. In certain aspects, thecomputing system can further include a conflict module 360 that assuresa deployed document container does not conflict with other applicablepolicies and/or map constraints, which may result in an error condition.

FIGS. 4-5 depict first and second example aspects of map data 118,particularly map data relative to the illustrated travel way portions,according to example embodiments of the present disclosure. Aspreviously described, map data 118 can include a wealth of informationregarding the identity and location of different travel ways (e.g.,roads, road segments, lanes, lane segments, parking lanes, turninglanes, bicycle lanes, or other portions of a particular travel way),buildings, maintenance/service locations for the autonomous vehicles,parking areas, traffic signs, traffic lights, traffic control devices,and/or any other map data that provides information that assists thecomputing system in comprehending and perceiving its surroundingenvironment and its relationship thereto. The particular identifiersdiscussed in FIGS. 4-5 for representing map data 118 can also be used torepresent constraint data 120 and/or travel routes determined by routedeterminer 122.

FIG. 4 illustrates information about each travel way within map data 118can be provided in detailed form. For instance, a portion of road 400can be represented within map data 118 as a plurality of road segments410, 420, and 430. Each road segment can respectively include one ormore lanes. In the example of FIG. 4, road segment 410 includes two lanesegments 412 and 414 associated with travel in a first direction and twolane segments 416 and 418 associated with travel in a second direction(e.g., opposing the first direction). Road segment 420 includes two lanesegments 422 and 424 associated with travel in a first direction and twolane segments 426 and 428 associated with travel in a second direction(e.g., opposing the first direction). Road segment 430 includes two lanesegments 432 and 434 associated with travel in a first direction and twolane segments 436 and 438 associated with travel in a second direction(e.g., opposing the first direction).

Referring now to FIG. 5, each travel way within map data 118 can bedefined using additional and/or alternative data than depicted in FIG.4. For instance, each travel way portion (e.g., lane segments 412-418,422-428, 432-428) can include a lane segment identifier, a road segmentidentifier, a road identifier, a district identifier, a start point, anend point, a directionality vector indicating a direction of trafficflow between start and end points, and/or connectivity identifiers forother travel way portions that are predecessors and/or successorsthereto. For example, lane segment 428 can be defined using lane segmentidentifier 428, road segment identifier 420, road identifier 400, startpoint 440, end point 442, a directionality vector 444 indicating thedirection of traffic flow between start point 440 and end point 442, andan indication that lane segment 428 is connected to predecessor lanesegment 418 (of road segment 410) and successor lane segment 438 (ofroad segment 430).

In some implementations, map data 118, constraint data 120 and/or travelroutes determined by route determiner 122 can be identified in terms ofparticular districts or coverage areas that include some or all of suchdata. For instance, travel way portion identifiers such as described,for example, in FIGS. 4-5 can be additionally identified in terms ofwhat district or coverage area they are included in. By breaking a mapdown into different districts or coverage areas, the disclosed systemsand methods can more easily identify which portions of map data 118 needto be evaluated relative to constraint data 120 to determine appropriatetravel routes.

FIGS. 6-7 depict additional aspects of map data including exampleconstraint data generated within an example geographic locationaccording to example embodiments of the present disclosure. Moreparticularly, FIG. 6 graphically depicts a portion of map data 600 thatincludes a plurality of travel way portions 602 along which anautonomous vehicle can be controlled to navigate within the particulargeographic location represented by map data 600. Travel way portions 602can include a combination of different travel way portions (e.g., lanesegments, road segments, etc.) that are included within the displayedportion of map data 600.

FIG. 7 depicts the same map data 600 provided in FIG. 6 along withadditional constraint data in the form of a polygon 604. In thisparticular example, polygon 604 has a first application typecorresponding to an “exclusion” type and a second application typecorresponding to a “partial” type. In other words, polygon 604 is apartial exclusion polygon 604, and has a predetermined boundary thatencompasses a geographic area within a portion of the map data 600.Although exclusion polygon 604 is shown to include four vertices andfour edges, the boundary of an exclusion polygon or other polygon caninclude any number of vertices and edges in a variety of configurationsand can sometimes be shaped relative to the locations of nearby travelway portions.

When the map data 600 of FIG. 7 is evaluated relative to the constraintdata (e.g., partial exclusion polygon 604), permitted and/or forbiddentravel way portions can be determined. In this particular example,assuming that polygon 604 was received in a constraint file having adefault “permit” state, all travel way portions should be permittedexcept for those travel way portions that are either completely enclosedor partially touched by exclusion polygon 604. Because travel wayportions 606, 608, 610 and 612 in FIG. 7 are either completely enclosedor partially touched by exclusion polygon 604, travel way portions606-612 are determined to be forbidden travel way portions. When anautonomous vehicle initially determines a travel route or updates apreviously determined travel route based on the constraint data of FIG.7, travel routes that include travel way portions 606-612 will beforbidden.

FIG. 8 depicts another example of map data and constraint data,particularly illustrating example exclusion polygons that may be createdusing the disclosed systems and methods to prevent an autonomous vehiclefrom using travel way portions that lead to or through a bridge within aparticular geographic area. An example of this nature could arise, forinstance, during planned construction that causes a bridge to be closedfor an extended period of time or during an accident that temporarilyaffects navigation over such a bridge. FIG. 8 depicts map data 800 thatincludes travel way portions 802, 804, and 806 along a bridge. Exclusionpolygons 808, 810, and 812 can be created to exclude respective travelway portions 802, 804, and 806 from permissible travel way portions forthe determined travel routes of one or more autonomous vehicles.Additional exclusion polygons 814, 816, 818 and 820 can be created toexclude additional travel way portions, for example, travel way portionsthat directly or indirectly lead to the travel way portions 802-806along the bridge.

FIG. 8 further depicts an example map constraint interface 830 based ona unified document model, according to examples described herein. Themap constraint interface 830 can include an autonomy map documentselection feature 840 that enables the fleet operator to select anautonomy map document at 842 from an autonomy map database. The selectedautonomy map document 800 can be displayed once selected, and the fleetoperator can interact with various features of the map constraintinterface 830 to create a shape at 844 and configure an input constraintfor the shape at 846 (e.g., utilizing a category 847 and effect 848manifest). In the example shown, the fleet operator can configure shapes(e.g., shapes 808, 810, 812, 814, 816, 818, 820) encompassing respectiveroute segments of roads (e.g., roads 802, 804, 806, etc.), and selectparticular map constraints (e.g., effects including, e.g., departconstraints) to be applied to each route segment encompassed by aparticular shape.

In addition, the map constraint interface 830 can also enable the fleetoperator to edit or append existing shapes on the autonomy map document800. For example, the map constraint interface 830 can enable theoperator to select a particular map constraint layer at 850, provideannotations at 852, toggle the layer to activate or deactivate the mapconstraint layer at 854, and/or deploy the updated autonomy map documentto selected AVs at 856.

As an example, a route portion of the autonomy map document may beoverlaid with multiple map constraint layers 860. In the navigationalconstraint category, the route portion may be overlaid with a forbiddenrouting constraint layer and an autonomy mode routing constraint layer.To prevent conflicting layers, the layers can be configured inaccordance with a subsumption order (e.g., either manually configured bythe fleet operator or automatically applied). The subsumption ordercomprises a hierarchy to which the AV is to treat the multiple layers.For example, the forbidden routing constraint layer, when activated, canoverride all lower order subsumption layers in the navigationalconstraint category for the particular route portion.

As described herein, a unified document model enables the fleet operatorto use the map constraint interface 830 to apply any number of mapconstraint layers 860, in any shape, to a particular autonomy mapdocument. Furthermore, each map constraint layer 860 can readily beactivated or deactivated using the toggle feature 854 on the mapconstraint interface 830. Thus, for a given autonomy map document, thefleet operator can configure route portions on the autonomy map documentto be layered with various map constraints of different categories(e.g., navigational constraints, perception constraints, predictionconstraints, etc.), each toggled as activated or deactivated at 854.

In various examples, the fleet operator may also provide targetedannotations readable by the AV control system, which can provide the AVwith contextual information that can affect one or more of thesequential AV operations (e.g., perception, prediction, or motionplanning). For example, the fleet operator can provide annotationsindicating a blind driveway or a pothole for the perception operationsof the AV. As another example, the fleet operator can provideannotations indicating a frequent deer crossing for both perception andprediction operations of the AV. In certain implementations, the mapconstraint interface 830 can further enable the fleet operator to selectAVs to which the autonomy map document is to be sent.

In accordance with embodiments described herein, the unified documentmodel can comprise a series of autonomy map documents readily editableby the fleet operator in the manner described herein. Thus, the fleetoperator can access any autonomy map document and, for example, toggle(activate or deactivate) existing map constraint layers at 854, createnew map constraint layers at 840-848, and provide annotations at 852 forany route portion of the autonomy grid map. For example, if aconstruction project is scheduled for a certain route segment, the fleetoperator can access the corresponding autonomy map document via the mapconstraint interface 830 and append an annotation to the documentindicating the construction zone, and/or activate a particularnavigational constraint to either forbid the AV from entering theconstruction zone, or cause the AV to be routed around it.

Once a set of autonomy map documents is finalized, the fleet operatorcan select a finalization or deploy feature 856 on the map constraintinterface 830. The computer system can respond to deployment selectionby flattening or compressing the map constraint layers of each documentinto a document image and compile the document images representing eachautonomy map document into a document container. The document containermay then be transmitted over-the-air to the selected AVs 102. Theselected AVs 102 then can merge the document images of each autonomy mapdocument into the corresponding existing autonomy map.

Accordingly, using the computer system and unified document modelarchitecture described herein, the existing policy can be updatedwithout the need for providing an entirely new autonomy map release.

In certain implementations, the map constraint interface 830 may alsoprovide a policy mask feature that enables the fleet operator tooverride an entire existing policy utilized by the AVs. For example, anAV 102 may operate in accordance with an existing policy using anautonomy map for a current route segment. The existing policy cancomprise a set of labels and or rules (e.g., initial map constraints)that the AV 102 must abide by when traversing the current route segment.The map constraint interface 830 can provide a policy mask feature thatcauses the entire policy to be overridden in favor of an updated policy(or a new set of map constraints).

The unified document model can be managed by a computer system thatcomprises a communication interface communicating, over one or morenetworks, with AVs that utilize autonomy maps to navigate throughout agiven region. The computer system can generate the map constraintinterface enabling the fleet operator to update map constraints for theAVs. In doing so, the computer system can receive, via the mapconstraint interface 830, a set of inputs configuring a set ofconstraint layers of one or more autonomy map documents corresponding toone or more autonomy maps 800. The computer system may then compile theautonomy map documents comprising a set of updated map constraintscorresponding to the configured set of constraint layers into a documentcontainer and output the document container to a subset of AVs to enablethe subset of AVs to integrate the set of updated map constraints withthe existing autonomy maps.

The computer system can also tabulate, in metadata of a given autonomymap document, a set of lane identifiers such as entry point identifiersand exit point identifiers of selected route portions to which a givenset of map constraints apply. In further examples, the computer systemcan generate metadata for the document indicating a creation time forthe document, a number of constraint layers created, a number ofconstraints created, a number of shapes created, and/or the last timethe document was modified and deployed to AVs. Along these lines, thecomputer system can manage a set of audit logs for tracking the historyof map constraint updates based on the generated metadata of eachautonomy map document.

In certain implementations, the AV 102 can communicate a constraintmanagement state to the computer system, indicating the operationalconstraints currently applied by the AV control system. For example,when the AV 102 starts up, the AV 102 can transmit an initialcommunication of the constraint management state of the AV 102 to thecomputer system, which can determine whether the AV 102 has applied thecurrent autonomy map updates. If not, then the computer system cantransmit a document container comprising the updated autonomy mapdocument images to the AV 102 for integration into the existing autonomymaps.

In some examples, the map data 600 and 800 of FIGS. 6-8 and associatedconstraint data can be generated using a software application andcorresponding graphical user interfaces provided on a remote computingdevice such as remote computing device(s) 150 of FIG. 2. For example,specific portions of map data (e.g., map data 600, 800) can beidentified by providing a specific address, landmark, latitude andlongitude or other geographic identifier in a search interface featurewithin a graphical user interface. Map data then can be retrieved from amaps database corresponding to a geographic area surrounding thegeographic identifier. In some examples, map data can be retrieved thatcorresponds with the same map data locally available at particularautonomous vehicles or fleets of autonomous vehicles.

Polygons (e.g., exclusion polygons 604, 808-820) or other constraintdata can be drawn within a graphical user interface containing map data(e.g., map data 600, 800) using a drawing tool feature. For instance, auser can provide input to select the location of the vertices of eachpolygon using, for example, mouse clicks, keyboard entry or other inputdevice selection. Polygon edges between the identified vertices can thenbe formed automatically by the drawing tool feature. The polygons orother constraint data can be defined in terms of global map coordinatesthat translate to similar global map coordinates provided within mapdata corresponding to a same geographic location or area. In someimplementations, one or more polygons or other constraint data can besaved as one or more separate constraint files for selectively uploadingand applying to one or more autonomous vehicles, fleets of vehicles,and/or geographic districts.

FIGS. 6-8 make use of geographic identifiers in the form of polygonshaving application types in the form of an exclusion type. It should beappreciated that constraint data can be provided in a variety ofadditional or alternative suitable formats. For example, geographicidentifiers can include, for example, one or more polygons encompassinga geographic area, one or more travel way identifiers indicative of atleast a portion of one or more lanes within a particular travel way, orother identifiers. In some implementations, the application typeassociated each geographic identifier can be selected from apredetermined group of application types (e.g., complete inclusion,partial inclusion, complete exclusion, partial exclusion, etc.). Inanother example, the application type can be selected as a value fromwithin a range of possible application type values (e.g., a numberselected from within a range of 0-10 with 0 being least permissible and10 being most permissible). In another example, an application type cancorrespond to an associated cost factor for navigating in a particulargeographic area.

FIGS. 9-10 depict example user interfaces 940 and 980 for applyingconstraint data according to example embodiments of the presentdisclosure. In some examples, user interfaces 940, 980 or others can beprovided as part of a software application provided on a remotecomputing device such as remote computing device(s) 150 of FIG. 2. Insome examples, the software application providing graphical userinterfaces 940 and 980 can also provide graphical user interfaces fordisplaying and creating the map data and constraint data depicted inFIGS. 6-8.

FIG. 9 illustrates graphical user interface 940 that can afford acomputing device user the ability to perform a variety of functions. Forinstance, graphical user interface 940 can include an interface portion941 that can be used to view all constraint data (e.g., identified byspecific constraint files) created by a software application,independent of which constraint data is applied to a particular vehicleor fleet of vehicles. Interface portion 942 can include one or moredistricts that correspond to the area including each particularconstraint file identified in interface portion 941, while interfaceportion 943 can include an optional additional description describingwhat each constraint file identified in interface portion 941represents. For each constraint file identified in interface portion941, an additional interface portion 944 can identify one or morevehicles to which each constraint file is attached, as well as when theconstraint file was added, who added the constraint file to the softwareapplication, and whether the constraint file is currently applied. Oneor more selectable interface elements 945 can be provided to deleteexisting constraint files. One or more selectable interface elements 946and/or 947 can be provided to upload new constraint files. One or moreselectable interface elements 948 can be provided to apply selectedconstraint files to particular vehicles(s), fleet(s) and/or district(s).

In sample embodiments, the constraint files are used to implementconstraints over the map of an autonomous vehicle by producing sets offorbidden lanes or high cost lanes to limit vehicle operation areas. Theconstraint files are composed primarily of polygons with globalgeographic coordinates (e.g., using UTM) defining which regions arepermitted for routing and which regions are forbidden for routing.Evaluating the constraints to decide whether a lane is permitted orforbidden requires loading lane geometry from the map and comparingagainst multiple polygons from the constraints file. In sampleembodiments, a vehicle command geosearch index may be used tosignificantly speed up constraints evaluation against the constraintpolygons. All types of constraints described herein may be evaluatedusing the same evaluation patterns. For example, the algorithm mayevaluate all lanes in an autonomous vehicle map entry point and a set ofconstraints polygons. Then, for each lane in the autonomous vehicle mapand for each polygon in the constraint definition, the algorithm checksif the lane geometry overlaps with the polygon. If yes, this is aforbidden lane. However, as the autonomous vehicle map gets larger andlarger, this implementation is not very efficient. Constraint evaluationideally happens in real-time on the autonomous vehicles, and poorperformance would have a bad impact on autonomous vehicle operations.

The constraints evaluation may be significantly sped up using a vehiclecommand geosearch index library. In a sample embodiment, two levels ofevaluation (submap and lane levels) are applied. A submap is evaluatedagainst a constraint polygon. If the submap and polygon is disjoint,then there is no need to go to lane level evaluation. This polygon hasno effect on all lanes within this submap. Also, if the submap is fullycontained within the polygon, then there is no need to go to lane levelevaluation. All lanes within this submap are forbidden. Otherwise lanelevel evaluation is performed whereby for every lane in the submap thelanes are checked against the polygon. Given a constraints polygon, thequery geosearch index is used to obtain a list of potential submaps forthe first level evaluation.

In some implementations, user selection of an interface element such asinterface elements 945-948 can initiate the display of additional oralternative graphical user interfaces. For example, selecting aparticular constraint file followed by selection of interface element948 in graphical user interface 940 of FIG. 9 can initiate the displayof an additional graphical user interface 980 as depicted in FIG. 10.Graphical user interface 980 can include one or more selectableinterface elements for identifying particular application targets for agiven constraint file. For instance, user selection of interface element982 can be used to apply selected constraint files to one or moreparticular vehicles as identified in drop down menu 988. User selectionof interface element 984 can be used to apply selected constraint filesto one or more particular fleets of vehicles, also as identified usingdrop down menu 988. User selection of interface element 986 can be usedto apply selected constraint files to one or more particular districtsusing, for example, drop down menu 988. Once a constraint file isselected for application using graphical user interfaces 940 and/or 980,such constraint files can be transmitted to one or more autonomousvehicles 102 over a network (e.g., network 180 of FIG. 2). Once receivedby an autonomous vehicle 102, the constraint files can be manually orautomatically accepted by the autonomous vehicle and used to determinenew and/or updated travel routes.

FIG. 11 depicts an example flow chart of a first example method 1100 ofcontrolling navigation of an autonomous vehicle 102 according to exampleembodiments of the present disclosure. One or more portion(s) of themethod 1100 can be implemented by one or more computing devices such as,for example, the computing device(s) 106 of FIG. 1. Moreover, one ormore portion(s) of the method 1100 can be implemented as an algorithm onthe hardware components of the device(s) described herein (e.g., as inFIGS. 1 and 2) to, for example, control the motion of an autonomousvehicle 102. FIG. 11 depicts elements performed in a particular orderfor purposes of illustration and discussion. Those of ordinary skill inthe art, using the disclosures provided herein, will understand that theelements of any of the methods discussed herein can be adapted,rearranged, expanded, omitted, combined, and/or modified in various wayswithout deviating from the scope of the present disclosure.

The method 1100 can include accessing, retrieving, or otherwiseobtaining map data descriptive of an identity and location of differenttravel ways within the surrounding environment of the autonomous vehicleat 1102. The map data accessed at 1102 can include at least a portion ofmap data 118 described in FIGS. 1-2. The map data accessed at 1102 canprovide information regarding the identity and location of differenttravel ways (e.g., roads, road segments, lanes, lane segments, parkinglanes, turning lanes, bicycle lanes, or other portions of a particulartravel way). In some examples, travel way portions within map dataaccessed at 1102 can include one or more descriptors including, forexample, a district identifier for a map coverage area containing thetravel way portion, a travel way portion identifier, a start point forthe travel way portion, an end point for the travel way portion, adirectionality (e.g., direction of traffic flow), and/or connectivityidentifiers for other travel way portions that are predecessors and/orsuccessors to a given travel way portion. Map data accessed at 1102 canalso include the identity and location of different items than travelways, including but not limited to buildings, maintenance/servicelocations for the autonomous vehicles, parking areas, traffic signs,traffic lights, traffic control devices, and/or any other map data thatprovides information that assists the computing system in comprehendingand perceiving its surrounding environment and its relationship thereto.

Method 1100 also can include accessing, retrieving, or otherwiseobtaining constraint data descriptive of one or more geographic areasand/or geographic identifiers within a map at 1104 (e.g., map dataaccessed at 1102) for which associated navigational constraints aredefined. The constraint data accessed at 1104 can include at least aportion of constraint data 120 described in FIGS. 1-2. Constraint dataaccessed at 1104 can include different forms of information describingnavigational constraints. For example, constraint data can include apriori map constraints identifying particular travel way portions fromwhich an autonomous vehicle 102 should be excluded or have a reducedlikelihood of operation. For instance, constraint data accessed at 1104can prevent or reduce the likelihood of an autonomous vehicle 102 makinga left hand turn in particular turn lanes of a given travel way ortravel way portion when a vehicle is operating in a particular mode(e.g., fully autonomous mode).

In some implementations, constraint data accessed at 1104 can includeone or more portions of base constraint data applied to a particularautonomous vehicle. In some implementations, the portions of baseconstraint data selected for application to a particular vehicle candepend at least in part on factors such as the operation location,operating mode, or other factors associated with each autonomousvehicle. Different operating modes can include, for example, a fullyautonomous mode in which an autonomous vehicle 102 operates without ahuman driver present in the vehicle, an autonomous mode in which theautonomous vehicle operates with a human driver in the vehicle, or othermodes. Different operating modes can additionally or alternativelyinclude, for example, whether a vehicle is currently engaged (e.g.,on-task) or not engaged (e.g., off-task) in performing a service. Forinstance, some vehicles may currently have passengers on board that arebeing driven from one location to another, while other vehicles may beengaged in controlled navigation but not currently engaged in aparticular operational task.

The method 1100 can further include receiving one or more constraintfiles descriptive of additional navigational constraints for one or moregeographic areas and/or geographic identifiers at 1106. In someimplementations, the one or more constraint files received at 1106 canbe received from one or more remote computing devices that are remotefrom the autonomous vehicle and that are configured to control operationof a fleet of autonomous vehicles. The one or more constraint files canbe generated by the one or more remote computing devices, for example,in response to identification of an event at some geographic locationthat will impact navigation at such location (e.g., a street fair,sporting event, traffic accident, parade, etc.) at a present and/orfuture time.

Each constraint file received at 1106 can include a constraint setincluding zero or more geographic identifiers (e.g., polygons havingboundaries defined relative to a geographic area and having anassociated application type) as well as a default state (e.g., permit,forbid) indicating whether to by default permit or forbid areasdescribed by the constraint file. Each geographic identifier describedby the constraint file(s) received at 1106 can be provided in a varietyof suitable formats. Geographic identifiers can include, for example,one or more polygons encompassing a geographic area, one or more travelway identifiers indicative of at least a portion of one or more laneswithin a particular travel way, or other identifiers. Application typesassociated with each geographic identifier provided within theconstraint file(s) received at 1106 can also be provided in a variety ofsuitable formats. For example, the application type associated with eachgeographic identifier can be selected from a predetermined group offirst application types (e.g., inclusion, exclusion, etc.). In anotherexample, the application type associated with each geographic identifiercan be selected from a predetermined group of second application types(e.g., partial, complete, etc.) In another example, the application typecan be selected as a value from within a range of possible applicationtype values (e.g., a number selected from within a range of 0-10 with 0being least permissible or preferred and 10 being most permissible orpreferred). In another example, an application type can correspond to anassociated cost factor for navigating in a particular geographic area.

Method 1100 can further include generating composite constraint data at1108. Generating composite constraint data at 1108 can include modifyingthe constraint data accessed at 1104 based at least in part on the oneor more constraint files received at 1106. Constraint data includedwithin the one or more constraint files received at 1106 can eitherappend or revise existing constraint data. In some examples, existingconstraint data includes base constraint data determined for aparticular vehicle. In some examples, existing constraint data includesbase constraint data as well as constraint data received in one or morepreviously received constraint files. In such instances, constraintfiles received at 1106 can sometimes completely overwrite previouslyreceived constraint files such that modifying constraint data at 1108includes removing previously received constraint files and adding newlyreceived constraint files. In some examples, constraint files receivedat 1106 are added to and/or combined with previously received constraintfiles when modifying constraint data at 1108.

In some implementations, the constraint data accessed at 1104 caninclude one or more inviolate constraints. Inviolate constraints caninclude those constraints that should not be changed or overwritten dueto a level of importance in their application during autonomousnavigation. In such instances, modifying constraint data at 1108 caninclude adding to or revising the constraint data accessed at 1104 in amanner that does not conflict with inviolate constraints within theconstraint data. The modification of constraint data at 1108 can beimplemented such that composite constraint data always includes anyinviolate constraints. In other words, modification of constraint dataat 1108 should not remove any constraints from the constraint dataaccessed at 1104 that are identified as inviolate constraints.

The method 1100 can further include determining a travel route fornavigating the autonomous vehicle 102 at 1110. The travel routedetermined at 1110 can be determined at least in part from map dataaccessed at 1102 evaluated relative to the composite constraint datagenerated at 1108. For example, the map data accessed at 1102 can beevaluated in association with the composite constraint data generated at1108 to determine which travel way portions are permitted and/or whichtravel way portions are forbidden from possible navigable travel wayswithin a set of map data. In some examples, a travel route can bedetermined at 1110 that does not include a forbidden travel way portion.

In some examples, a travel route can be determined at 1110 that givespreference to travel way portions having an application type associatedwith a lower cost factor. When constraint data includes applicationtypes associated with cost factors, one or more computing devicesassociated with an autonomous vehicle 102 can determine a travel routeat 1110 that minimizes a total cost based at least in part on costfactors associated with application types included as part of constraintdata 120 as well as optional additional cost factors, cost functions orthe like for other navigational objectives. Depending on the manner ofapplication type, travel routes can be determined at 1110 that not onlycan exclude particular areas from navigation but that additionally oralternatively can reduce traffic in particular areas based at least inpart on evaluation of the constraint data.

A travel route determined at 1110 can include, for example, a sequenceof multiple travel way portions along which an autonomous vehicle cannavigate, for example, to accomplish a predetermined navigationalobjective. Each travel way portion within a determined travel route canbe defined by one or more of a travel way identifier, a start point, anend point, directionality, and/or connectivity identifiers forpredecessor and/or successor travel way portions.

In some examples, travel routes determined at 1110 can be determined inaccordance with a navigational objective (e.g., traveling to adestination location to perform a service such as rideshare service,delivery service, courier service, etc.). In some examples, travelroutes determined at 1110 can be determined to accomplish thenavigational objective using travel way portions that are permittedand/or preferred as opposed to forbidden and/or not preferred based onmap data evaluated in association with constraint data. In someimplementations, for example, it may be desirable to forbid or notprefer specific areas or specific travel ways within an area due toevents such as a traffic accident, street fair, construction, a parade,or the like. In other implementations, for example, it may be desirableto permit or prefer specific areas or specific travel ways within anarea for navigation by particular autonomous vehicles that are assignedto perform services in a given area, thus affording efficientdistribution of fleet resources.

The method 1100 can further include sending a notification signal at1112. In some examples notification signals sent at 1112 can be sentfrom a vehicle computing device 106 as depicted in FIGS. 1 and 2. Insome examples, notification signals sent at 1112 can be sent to one ormore remote computing devices 150 as depicted in FIG. 2. In someexamples, notification signals sent at 1112 can be sent over a network180 as depicted in FIG. 2. In some implementations, a notificationsignal sent at 1112 can include one or more of an acknowledgement ofreceipt of the one or more constraint files received at 1106 and/or aconfirmation of modification of constraint data at 1108. In someimplementations, a notification signal sent at 1112 can additionally oralternatively include the travel route determined at 1110.

The method 1100 can include detecting one or more objects that areproximate to the autonomous vehicle 102 at 1114 as it navigates alongthe travel route determined at 1110. Detection of objects at 1114 can beimplemented by analyzing sensor data obtained from one or more sensors(e.g., image capture devices, RADAR devices, LIDAR devices, etc.) 104depicted in FIG. 1. The perception system 110 of FIG. 1 can detectobject(s) including, for example, pedestrians, other vehicles, bicycles,barriers, boundaries, traffic control devices, etc. The sensor data canbe indicative of locations associated with the object(s) within thesurrounding environment of the autonomous vehicle at one or moretime(s). Perception system 110 can further analyze the sensor data todetect certain objects as objects of interest from background or otherobjects.

The method 1100 can include controlling motion of the autonomous vehicleat 1116 based at least in part on the travel route determined at 1110and/or the one or more objects detected along the travel route at 1114.Motion of an autonomous vehicle 102 can be controlled at 1116 bydetermining a motion plan relative to the travel route. The motion plancan be configured to generally follow the travel route whileconcurrently planning to navigate appropriately relative to any detectedobjects proximate to the autonomous vehicle (e.g., pedestrians, othervehicles, traffic control devices, etc.) that are detected by thevehicle's sensors.

In some implementations, controlling motion of a vehicle at 1116 can bedone in accordance with an optimization algorithm that considers costfactors associated with the constraint data (e.g., application typeshaving associated cost factors) as well as other cost factors orfunctions (e.g., based on speed limits, traffic lights, etc.), if any,to determine optimized variables that make up a motion plan. By way ofexample, motion of a vehicle can be controlled in a manner thataccomplishes a navigational objective using permitted travel wayportions from a travel route determined at 1110 without increasing thepotential risk to the vehicle 102 and/or violating any traffic laws(e.g., speed limits, lane boundaries, signage).

Controlling motion of a vehicle at 1116 can include providing dataindicative of a motion plan to a vehicle controller to implement themotion plan for the autonomous vehicle 102. For instance, an autonomousvehicle 102 can include a vehicle controller 116 as depicted in FIG. 1that is configured to translate the motion plan into instructions. Byway of example, the vehicle controller 116 can translate a determinedmotion plan into instructions to adjust the steering of the autonomousvehicle 102 “X” degrees, apply 10% braking force, modulate a speed ofthe autonomous vehicle 102, etc. The vehicle controller 116 can send oneor more control signals to components of the vehicle controls 108 (e.g.,braking control component, steering control component, speed/throttlecontrol component) to execute the instructions and implement the motionplan.

FIG. 12 depicts a flow chart of an example method 1200 of determining atravel route for an autonomous vehicle, such as referred to in 1110 ofFIG. 11. One or more portion(s) of the method 1200 can be implemented byone or more computing devices such as, for example, the computingdevice(s) 106 of FIG. 1. Moreover, one or more portion(s) of the method1200 can be implemented as an algorithm on the hardware components ofthe device(s) described herein (e.g., as in FIGS. 1 and 2) to, forexample, control the motion of a vehicle. FIG. 12 depicts elementsperformed in a particular order for purposes of illustration anddiscussion. Those of ordinary skill in the art, using the disclosuresprovided herein, will understand that the elements of any of the methodsdiscussed herein can be adapted, rearranged, expanded, omitted,combined, and/or modified in various ways without deviating from thescope of the present disclosure.

As illustrated at 1202, the method 1200 can include obtaining aconstraint set having a default state (e.g., permit or forbid) and beingdescriptive of zero or more geographic identifiers (e.g., polygons) andassociated application types (e.g., complete inclusion, completeexclusion, partial inclusion, partial exclusion). In a specificimplementation, method 1200 can include obtaining at 1202 constraintdata descriptive of one or more polygons having an associatedapplication type. Each polygon can correspond, for example, to aninclusion polygon identifying an area for inclusion in a permissiblearea for navigation by an autonomous vehicle 102 and/or an exclusionpolygon identifying an area for exclusion from a permissible area fornavigation by an autonomous vehicle 102.

The method 1200 can further include at 1204 determining permitted travelway portions. For instance, permitted travel way portions can bedetermined as those travel way portions that are described by aconstraint set having a default “permit” state, that are completelyenclosed by a complete inclusion polygon, or that are completelyenclosed or partially touched by a partial inclusion polygon.

The method 1200 can further include at 1206 determining forbidden travelway portions. For instance, forbidden travel way portions can bedetermined as those travel way portions that are described by aconstraint set having a default “forbid” state, that are completelyenclosed by a complete exclusion polygon, or that are completelyenclosed or partially touched by a partial exclusion polygon. When atravel way portion is part of both an inclusion polygon and an exclusionpolygon, such travel way portion should be excluded. In other words,determination as an excluded travel way portion can trump determinationas an included travel way portion.

The method 1200 can further include at 1208 determining a travel routebased at least in part on permitted travel way portions determined at1204 and forbidden travel way portions determined at 1206. Determining atravel route at 1208 can be implemented, for example, by routedeterminer 122 of FIG. 1. Travel routes determined at 1208 canpreferably consist of permitted travel way portions determined at 1204without any of the forbidden travel way portions determined at 1206.

FIG. 13 depicts an example flow chart of a second example method 1300 ofcontrolling navigation of an autonomous vehicle according to exampleembodiments of the present disclosure. One or more portion(s) of themethod 1300 can be implemented by one or more computing devices such as,for example, the remote computing device(s) 150 of FIG. 2. In someexamples, such remote computing device(s) can be included as part of acentral control system that is in wireless communication with aplurality of autonomous vehicles, such as a fleet of autonomous vehiclesproviding one or more services (rideshare service, delivery service,courier service, etc.).

Moreover, one or more portion(s) of the method 1300 can be implementedas an algorithm on the hardware components of the device(s) describedherein (e.g., as in FIG. 2) to, for example, control the motion of avehicle. FIG. 13 depicts elements performed in a particular order forpurposes of illustration and discussion. Those of ordinary skill in theart, using the disclosures provided herein, will understand that theelements of any of the methods discussed herein can be adapted,rearranged, expanded, omitted, combined, and/or modified in various wayswithout deviating from the scope of the present disclosure.

As illustrated at 1302, the method 1300 can include creating aconstraint set with zero or more geographic identifiers and having adefault state (e.g., permit or forbid). The default state can indicatewhether to by default permit or forbid areas described by a constraintset and/or constraint file that includes the constraint set.

The method 1300 can further include at 1304 identifying an event at somegeographic location that will impact navigation at such location (e.g.,a street fair, sporting event, traffic accident, parade, etc.).Identification of one or more events at 1304, for which the disclosedconstraint data can be determined, can come from data descriptive of anupcoming event (e.g., sporting event or the like) and/or historical data(e.g., by approximating navigational limitations based on past events ina particular geographic region at a certain time and/or date).Identification of one or more events at 1302 can be implemented usingvarious databases to predict, approximate, and/or determine the eventsand/or geographic locations of anticipated navigational limitations. Forexample, for different geographic regions, event information (e.g.,location, time, and/or date of the event, or the like) can be stored inan event database. Event information can be indicative of whethertraffic can be higher or lower at a certain time period (e.g., a timeperiod before the event begins versus a time period when the event isongoing). In another example, event information can come from calendardatabases that indicate important dates (e.g., holidays, first days ofschool for a city, voting day, or the like). Other examples of outsidesources or other stored data (e.g., predicted future, current and/orhistoric events, conditions, or the like) include weather conditions,news information (e.g., fires, emergency situations, or the like),social information (e.g., via social networking websites), trafficconditions, flight information from airports and/or airlines, or thelike, or other information that can assist in determining eventinformation, traffic patterns or other data contributing to potentialnavigational constraints.

For each event identified at 1304, constraint data associated with theidentified event can then be determined. For example, at 1306 the method1300 can include determining one or more geographic identifiersassociated with the event. For example, determining a geographicidentifier at 1306 can include determining a polygon having a boundarydefined relative to a geographic area including the location of theevent. In some implementations, the polygon can have a boundary thatencompasses a geographic area including the location of the identifiedevent. Each geographic identifier determined at 1306 can also have anassociated application type (e.g., inclusion, exclusion, complete,partial) for the geographic identifier (e.g., the polygon). In someexamples, determining one or more geographic identifiers at 1306 can beimplemented using a drawing tool feature such as described withreference to FIGS. 6-8.

The method 1300 can further include assigning at 1308 the one or moregeographic identifiers to the constraint set created at 1302. Aconstraint file including the constraint set then can be transmitted at1310 to one or more autonomous vehicles 102 over a network (e.g.,network 180 of FIG. 2). In some examples, transmitting constraint dataat 1310 can be initiated using one or more graphical user interfaces,such as graphical user interfaces 940, 980 of FIGS. 9-10.

FIG. 14 depicts an example system for providing up-to-date routeconstraint information to autonomous vehicles according to exampleembodiments of the present disclosure. In the below description of FIG.14, the remote computing device 1450 can correspond to the remotecomputing device 150 as shown and described with respect to FIG. 2, andthroughout the present disclosure. The remote computing device 1450 cancommunicate with a fleet of autonomous vehicles 1490 operatingthroughout a given region (e.g., a metropolitan area or predefinedoperational grid on a road network) over one or more networks 1480. Theremote computing device 1450 can further communicate with one or morecentral planning resources 1410 and/or one or more traffic monitoringresources 1405 over one or more networks 1480.

As described herein, the traffic monitoring resources 1405 can monitorlive traffic conditions for the given region and identify lane or roadsegments that are currently jammed with traffic, blocked, or otherwiseinaccessible. The traffic monitoring resources 1405 can be crowd-sourcedor updated by users of a live traffic mapping resource or application orcan comprise a central monitoring service that continually updatestraffic conditions on a granular level (e.g., every road segment of thegiven region). In some aspects, the traffic monitoring resources 1405can indicate the source for a live traffic constraint, as well as theroad or lane segment(s) affected. In doing so, the traffic monitoringresources 1405 can provide the remote computing device 1450 withcontextual information for the live traffic constraint. For example, thetraffic monitoring resources 1405 can classify the live trafficconstraints in terms of type (e.g., normal traffic jam, vehicleincident, spontaneous or unplanned event), estimated time of resolution(e.g., less than ten minutes, between ten and thirty minute, or greaterthan thirty minutes), and/or size of the traffic constraint (e.g.,whether multiple parallel road segments are constrained).

The central planning resources 1410 may be updated by central planningauthorities based on planned road and/or lane closures for the givenregion. For example, the central planning resources 1410 can indicatepermitted events requiring closure of a certain road segment during acertain time frame. Such permitted events can comprise parades,festivals, protests, road construction, utility servicing, and otherplanned events involving a road or lane closure.

In accordance with examples described herein, the remote computingdevice 1450 update the autonomy map constraints for the given regionbased on the planned lane or road closures indicated by the centralplanning resources 1410 and the live traffic constraints indicated bythe traffic monitoring resources 1405. In certain examples, the remotecomputing device 1450 can be manually operated by an administrator 1455.For manual implementations, the administrator 1455 can manually accessthe traffic monitoring resources 1405 and/or central planning resources1410 over one or more networks 1480 to determine any traffic or roadsegment constraints for the given region. The administrator 1455 maythen manually update autonomy map constraints that dictate road and lanesegments through which the autonomous vehicles 1490 may operate.

In variations, the autonomy map constraints may be automatically updatedby the remote computing device 1450. For example, the remote computingdevice 1450 can periodically or continuously parse through any livetraffic constraints and planned road or lane closures indicated by thetraffic monitoring resources 1405 and central planning resources 1410 toupdate the autonomy map constraints for the autonomous vehicles 1490.For example, updating of the autonomy map constraints (automatically ormanually) can correspond to establishing exclusion polygons for each ofthe traffic or road segment constraints identified by the trafficmonitoring resources 1405 or the central planning resources 1410. Theremote computing device 1450 may then transmit traffic flow constraintinformation identifying the closed road or segments to the autonomousvehicles 1490 over the network(s) 1480. For example, the remotecomputing device 1450 can generate a constraint file comprising thetraffic flow constraint information indicating the excluded roadsegments, and transmit the constraint file to the autonomous vehicles1490 over the network(s) 1480.

As described herein, the remote computing device 1450 can transmit thetraffic flow constraint information to all autonomous vehicles 1490 orselectively. For example, the remote computing device 1450 can manage anon-demand transport service that routes the autonomous vehicles 1490throughout the given region based on user demands (e.g., for freightdelivery, food delivery, passenger transport, etc.). In such examples,the remote computing device 1450 can selectively transmit the trafficflow constraint information to only those autonomous vehicles 1490 thatare routed to converge towards or intersect with the excluded road orlane segments.

Based on the traffic flow constraint information transmitted from theremote computing device 1450, the autonomous vehicles 1490 can performroute planning operations accordingly. For example, the remote computingdevice 1450 or other transportation coordination system can provide theautonomous vehicles 1490 with a sequence of destinations for makingpick-ups and drop-offs. The on-board of off-board computing systems ofthe autonomous vehicles 1490 can generate respective route plans toautonomously drive to a next destination. Based on the constraintfile(s), comprising the traffic flow constraint information, receivedfrom the remote computing device 1450, the autonomous vehicles 1490 caninherently avoid the exclusion zones or forbidden road segments.Accordingly, the remote computing device 1450 can leverage thelive-traffic constraints and planned closures indicated by the trafficmonitoring resources 1405 and central planning resources 1410 to createexclusion zones within the given region in which the autonomous vehicles1490 operate. The remote computing device 1450 can then generateconstraint files identifying the exclusion zones and transmit theconstraint files to the autonomous vehicles.

FIG. 15 depicts an example flow chart of a method 1500 of providingup-to-date route constraint information to autonomous vehicles accordingto example embodiments of the present disclosure. One or more portion(s)of the method 1500 can be implemented by one or more computing devicessuch as, for example, the remote computing device(s) 150, 1450 of FIGS.2 and 14. In some examples, such remote computing device(s) can beincluded as part of a central control system that is in wirelesscommunication with a plurality of autonomous vehicles, such as a fleetof autonomous vehicles providing one or more services (rideshareservice, delivery service, courier service, etc.). Furthermore, in thebelow description of FIG. 15, reference may be made to referencecharacters representing like features as shown and described withrespect to FIG. 14.

FIG. 15 illustrates the remote computing device 1450 receiving oraccessing traffic flow constraint information from one or more centralroad planning resources 1410 and/or traffic monitoring resources 1405 at1502. As described herein, the traffic flow constraint information maybe accessed and received manually by an administrator 1455 orautomatically by the remote computing device 1450. Based on the trafficconstraint information, the remote computing device 1450 can updateautonomy map constraints for autonomous vehicles 1490 operating in thegiven region at 1504. As provided herein, the “autonomy map” cancomprise a road grid within a road network on which the autonomousvehicles 1490 can operate. In certain implementations, the autonomy mapcorresponds to on-board sub-maps or localization maps that theautonomous vehicles 1490 utilize to compare with live sensor data.Accordingly, in updating the autonomy map constrains, the remotecomputing device 1450 can generate exclusion polygons or areas thatdefine forbidden road segments through which the autonomous vehicles1490 are forbidden to operate.

The remote computing device 1450 may then generate and transmitnon-routable data, indicating the autonomy map constraints, to theautonomous vehicles 1490 at 1506. In various examples described herein,the remote computing device 1450 generates a constraint file thatdefines the non-routable data (e.g., identifying the lane or roadsegments that are closed or blocked), and transmits the constraint fileto the autonomous vehicles 1490. Thereafter, the autonomous vehicles1490 are prevented from planning routes that enter the forbidden roadsegments.

As noted above, the inventors have recognized that there are manysituations where an FBR constraint is applied but the operators do notactually mean “do not enter this area and the only safe thing to do inthis area is stop moving.” What they actually mean is “do not enter thisarea and exit it if you are currently in it.” For example, in the caseof a planned parade route, it is undesirable for an autonomous vehicleto enter the parade route after the constraints annotating the paraderoute have been deployed. On the other hand, it is perfectly appropriatethat any autonomous vehicle currently traversing the parade route beallowed to continue moving, so long as the autonomous vehicle exits thearea of the parade route as expediently as possible as there is noimmediate safety risk. Constraints for implementing such a featuredescribed herein as depart constraints will now be described.

Generally speaking, depart constraints are associated with certain lanesto set them apart as depart constraint lanes, i.e., lanes that anautonomous vehicle should not enter and can only be used by theautonomous vehicle to leave the depart constraint area. The departconstraint area thus indicates that the area can be traversed byautonomous vehicles already inside the area when the constraints areimposed, that the area can be exited by autonomous vehicles alreadyinside the area, that autonomous vehicles outside the area cannot enterthe area after the depart constraints are imposed, and that traversalshould bias towards exiting the area as expediently as practical. Lanesmarked with a depart constraint should be avoided unless the autonomousvehicle is already in depart lanes. The depart lanes should only be usedfor leaving the constrained area and have high cost so that theautonomous vehicle will leave the area as soon as possible. The routedeterminer 122 will receive a list of depart constrained lanes forconsideration for optimal routing, though with the associated costs.Such operations provide fleet operators applying constraints with moreexpressive options in order to convey the actual behaviors they wish toimpart on the autonomous vehicle fleet while maintaining the highestpossible level of safety.

The depart constraint effect described herein may be implemented asfollows. The semantics of the depart constraint effect include a node(lane, or other similar logical graph unit consumed by a routing engine)marked by a depart constraint 1602 that may not be entered from any nodewhich is not also marked with a depart constraint as illustrated in FIG.16A. However, a node marked with a depart constraint 1604 may be exitedinto nodes which may or may not be marked with a depart constraint asillustrated in FIG. 16B. Also, a node marked with a depart constraint isconsidered “high cost” relative to nodes not marked with a departconstraint such that on average routes exit areas marked with a departconstraint are exited as expediently as practical, even if this resultsin a “less efficient” route 1606 from a distance/time perspective, asillustrated in FIG. 16C.

In terms of hierarchy within the navigation options, the departconstraint will be given opacity such that the only constraint effectthat can mask it is Forbid Routing. In order to support autonomousvehicle operations, it will be possible for a node to be marked bothRoutable Non-Auto (RNA) and Depart constraints. In this situation, asemi-autonomous vehicle will follow the normal Depart constraintsemantics but will be required to operate in manual mode. In a fullyautonomous vehicle context, such a node would be promoted to FBR due tothe RNA constraints through a constraints promotion process.

FIGS. 17 and 18 illustrate sample use case diagrams for the departconstraint feature.

FIG. 17 illustrates a use case for constraining out anon-immediate-safety-concern exclusion zone such as a parade route. Inthe scenario of FIG. 17, a pre-announced set of road closures, such as aparade route or running race route, have been received by the operator,who wishes to proactively clear the route of autonomous vehicles 102 andto ensure that new autonomous vehicles will not attempt to route throughthe road closures. For the sake of this example, it will be assumed thatthe environment of the parade route looks like FIG. 17A, with area 1702representing the expected road closure areas for the parade. In thisexample, autonomous vehicle 1704 is within the road closure area 1702and autonomous vehicle 1706 is outside the road closure area 1702. IfFBR constraints were applied to road closure area 1702 as in FIG. 17B,autonomous vehicle 1704 inside the road closure area 1702 would beinstructed to stop moving and would become stuck. On the other hand, theautonomous vehicle 1706 which is outside the road closure area 1702 isable to successfully reroute along route 1708 to avoid the road closurearea 1702.

However, as illustrated in FIG. 17C, if a depart constraint is appliedto road closure area 1702 instead of the FBR constraint, the autonomousvehicle 1704 inside the road closure area 1702 will continue to route,exiting the road closure area 1702 as soon as possible along route 1710.The autonomous vehicle 1706 outside the road closure area 1702 exhibitsthe same behavior as when under the FBR constraint, rerouting around theroad closure area 1702 along route 1708. In this manner, the departconstraint enables the autonomous vehicle 1704 to safely exit the roadclosure area 1702 without stranding any passengers in autonomous vehicle1704.

FIG. 18 illustrates a use case for escaping a localized safety hazardsuch as fallen power lines, a fallen tree, a burning bridge, a sinkhole,and the like. In the scenario of FIG. 18, a localized safety hazard hasarisen, such as a bridge 1800 catching on fire, or a sinkhole opening inthe road at 1802 as illustrated in FIG. 18A. In the immediate area ofthe safety hazard 1802 (in the node that's on fire, or is now a hole inthe ground), the safest thing to do is for the autonomous vehicle 1804to stop moving and to not complete route 1806. However, there is likelysome radius around the safety hazard 1802 where it remains desirable forthe autonomous vehicles, such as autonomous vehicles 1808 and 1810, tokeep moving along paths 1812 and 1814, respectively, while preventingautonomous vehicles that are not on the bridge from entering the bridgeor the lanes around the sinkhole 1802.

With only FBR constraints applied to the scenario of FIG. 18A, in orderto prevent new autonomous vehicles from entering the bridge, the entirebridge 1800 is constrained. As illustrated in FIG. 18B, this means thatautonomous vehicles 1804 and 1808 on the bridge 1800 stop moving and getstuck, potentially causing a safety hazard not only for their occupants,but for other motorists on the bridge 1800 behind them. On the otherhand, autonomous vehicle 1810 safely avoids the bridge 1800 bytraversing path 1816.

However, as illustrated in FIG. 18C, if a depart constraint is appliedto the bridge 1800 instead of the FBR constraint, the autonomous vehicle1804 inside the road closure area on bridge 1800 will be rerouted alongroute 1818, exiting the bridge as soon as possible. Similarly,autonomous vehicle 1808 inside the road closure area on bridge 1800 willcontinue to route along route 1820, exiting the bridge as soon aspossible. On the other hand, autonomous vehicle 1810 that is not on thebridge 1800 does not enter the bridge 1800 and instead reroutes alongpath 1816 as in the FBR example of FIG. 18B. Thus, with the departconstraint used in concert with an FBR constraint only on the node 1822including the localized safety hazard, the desired outcome is achieved.The autonomous vehicles 1804 and 1808 on the bridge 1800 are able tosafely escape, while the autonomous vehicle 1810 not on the bridge 1800is able to continue traveling without entering the potentially dangerousarea.

The depart constraint effect may be implemented in the same fashions asthe other constraints noted above. A new “depart” entry will be added toa configuration file for the new constraint effect to be implemented inthe navigation constraint system. The opacity of the depart constrainteffect is set to medium so that it will correctly mix with RNA but bemasked by FBR. The urgency of the “high cost” requirement for the departconstraint may be configurable separate from HCA constraint, the samecost as the HCA constraint, or a fixed ratio to HCA, as desired.

The depart constraints are implemented by the constraint deploymentmodule 350 (FIG. 3) by consolidating all constraints handling within theroute determiner 122 and route planning graph generation. Theconstraints may be managed by identifying lanes that are forbiddenlanes, force manual lanes, high cost lanes and depart lanes. In sampleembodiments, the route determiner 122 accepts (and makes a copy) ofthese lane sets as multiple separated items. Forbidden connections arereceived along with wide or narrow cost field constraints. For eachlane, the constraints manager returns the effect of all of theseconstraints. For each pair of lanes, the constraints manager returns ifit is forbidden or a high cost depart connection. A new cost parametermay be added for a depart lane, as appropriate. Also, cost overlays maybe used to overwrite the cost of a lane related to depart lanes. Theconstraints manager also accepts subscribers for constraint changesnotification and calls the subscribers' callback functions whenever aconstraint is changed. The routing logic is not changed; the routinglogic applies the weights or forbidden nature of a route when itcalculates its route through lanes marked with a depart constraint andbased on the location of the vehicle relative to the lanes marked withthe depart constraint. A routing engine for implementing the routinglogic may be included in the route determiner 122 on the vehicle or maybe included in an offboard system located in a cloud routing engine, forexample.

In sample embodiments, the routing engine in the route determiner 122receives the active route constraints (e.g., FBR, HCA, RNA, and Depart)as described herein along with a list of lanes that are to be consideredfor optimal routing. A high cost is assigned to the depart lanes asdescribed herein. The active constraints are received in a file, and theroute determiner 122 accepts and makes a copy of the lane set asmultiple separated items. The route determiner 122 also receivesforbidden connections and wide or narrow cost field constraints. Foreach lane, the active constraints are processed to apply the appropriateconstraints to the respective lanes. Similarly, for each pair of lanes,the active constraints are processed to determine if the lane pair isforbidden or a high cost depart connection. The constraint changes areprovided in notifications to subscribers to the routing data to indicatethat a constraint has been changed.

It will be appreciated by those skilled in the art that an autonomousvehicle that is moving when the depart constraints are imposed may enterthe lanes marked as depart lanes before it has time to stop and/orreroute. In such cases, the area occupied by the autonomous vehicle maybe expanded to include those lanes needed to stop and/or reroute theautonomous vehicle as it approaches lanes marked as depart lanes. Also,an area marked as a depart area may be expanded to fill in dead endsthat are created by the depart area. For example, in the example of FIG.18, the entire bridge may be marked as a depart area even if only onelane is affected by the hazard 1802. Also, connected components analysismay be used to find dead ends created by the imposition of the departarea onto a map. The depart area would be expanded to incorporate theconnected components as needed to avoid the creation of dead ends as aresult of imposition of the depart area onto the map.

Hardware Diagrams

The technology discussed herein makes reference to computing devices,databases, software applications, and other computer-based systems, aswell as actions taken and information sent to and from such systems. Oneof ordinary skill in the art will recognize that the inherentflexibility of computer-based systems allows for a great variety ofpossible configurations, combinations, and divisions of tasks andfunctionality between and among components. For instance,computer-implemented processes discussed herein can be implemented usinga single computing device or multiple computing devices working incombination. Databases and applications can be implemented on a singlesystem or distributed across multiple systems. Distributed componentscan operate sequentially or in parallel. Furthermore, computing tasksdiscussed herein as being performed at computing device(s) remote fromthe vehicle can instead be performed at the vehicle (e.g., via thevehicle computing system), or vice versa. Such configurations can beimplemented without deviating from the scope of the present disclosure.

FIG. 19 is a block diagram illustrating a computer system upon whichexample AV processing systems described herein may be implemented. Thecomputer system 1900 can be implemented using a number of processingresources 1910, which can comprise processors 1911, field programmablegate arrays (FPGAs) 1913. In some aspects, any number of processors 1911and/or FPGAs 1913 of the computer system 1900 can be utilized ascomponents of a neural network array 1912 implementing one or moremachine learning models and utilizing road network maps stored in memory1961 of the computer system 1900. In the context of FIG. 1, variousaspects and components of the AV computing device 106 can be implementedusing one or more components of the computer system 1900 shown in FIG.19.

According to some examples, the computer system 1900 may be implementedwithin an autonomous vehicle (AV) with software and hardware resourcessuch as described with examples of FIG. 1. In an example shown, thecomputer system 1900 can be distributed spatially into various regionsof the AV 102, with various aspects integrated with other components ofthe AV 102 itself. For example, the processing resources 1910 and/ormemory resources 1960 can be provided in a cargo space of the AV 102.The various processing resources 1910 of the computer system 1900 canalso execute control instructions 1962 using microprocessors 1911, FPGAs1913, a neural network array 1912, or any combination of the same. Inaddition, the computer system 1900 may be in communication with apassenger feedback system of the AV 102, which can include a feedbackcontroller comprising a set of processing and local memory resourcesstoring feedback instructions.

In an example of FIG. 19, the computer system 1900 includes acommunication interface 1950 that can enable communications over anetwork 1980. In one implementation, the communication interface 1950can also provide a data bus or other local links to electro-mechanicalinterfaces of the vehicle, such as wireless or wired links to and fromcontrol mechanisms 1920 (e.g., via a control interface 1921), sensorsystems 1930, and can further provide a network link to a backendtransport management system or a remote assistance system (implementedon one or more datacenters) over one or more networks 1980.

The memory resources 1960 can include, for example, main memory 1961, aread-only memory (ROM) 1967, storage device, and cache resources. Themain memory 1961 of memory resources 1960 can include random accessmemory (RAM) 1968 or other dynamic storage device, for storinginformation and instructions which are executable by the processingresources 1910 of the computer system 1900. The processing resources1910 can execute instructions for processing information stored with themain memory 1961 of the memory resources 1960. The main memory 1961 canalso store temporary variables or other intermediate information whichcan be used during execution of instructions by the processing resources1910. The memory resources 1960 can also include ROM 1967 or otherstatic storage device for storing static information and instructionsfor the processing resources 1910. The memory resources 1960 can alsoinclude other forms of memory devices and components, such as a magneticdisk or optical disk, for purpose of storing information andinstructions for use by the processing resources 1910. The computersystem 1900 can further be implemented using any combination of volatileand/or non-volatile memory, such as flash memory, PROM, EPROM, EEPROM(e.g., storing firmware 1969), DRAM, cache resources, hard disk drives,and/or solid-state drives.

The memory 1961 may also store localization maps 1964 in which theprocessing resources 1910—executing the control instructions 1962—cancontinuously compare to sensor data from the various sensor systems 1930of the AV 102. Execution of the control instructions 1962 can cause theprocessing resources 1910 to generate control commands 1915 in order toautonomously operate the AV's acceleration 1922, braking 1924, steering1926, and signaling systems 1928 (collectively, the control mechanisms1920). Thus, in executing the control instructions 1962, the processingresources 1910 can receive sensor data 1932 from the sensor systems1930, dynamically compare the sensor data 1932 to a current localizationmap 1964 and generate control commands 1915 for operative control overthe acceleration, steering, and braking of the AV 102. The processingresources 1910 may then transmit the control commands 1915 to one ormore control interfaces 1921 of the control mechanisms 1920 toautonomously operate the AV 102 through road traffic on roads andhighways, as described throughout the present disclosure.

The memory 1961 may also store routing information 1966 that theprocessing resources 1910 can utilize to determine routes for the AV 102to any given destination. In certain examples described herein, therouting information 1966 can further be provided to a network computingsystem 100 (FIG. 1) to enable the network computing system 100 to selector filter out the AV 102 as a candidate to service transport requests.

FIG. 20 is a block diagram that illustrates a computer system upon whichexamples described herein may be implemented. A computer system 2000 canbe implemented on, for example, a server or combination of servers. Forexample, the computer system 2000 may be implemented as part of anetwork service for providing transportation services. In the context ofFIGS. 1 and 2, the network computing system 100, 200 may be implementedusing a computer system 2000 such as described by FIG. 20.

In one implementation, the computer system 2000 includes processingresources 2010, a main memory 2020, a read-only memory (ROM) 2030, astorage device 2040, and a communication interface 2050. The computersystem 2000 includes at least one processor 2010 for processinginformation stored in the main memory 2020, such as provided by arandom-access memory (RAM) or other dynamic storage device, for storinginformation and instructions which are executable by the processor 2010.The main memory 2020 also may be used for storing temporary variables orother intermediate information during execution of instructions to beexecuted by the processor 2010. The computer system 2000 may alsoinclude the ROM 2030 or other static storage device for storing staticinformation and instructions for the processor 2010. A storage device2040, such as a magnetic disk or optical disk, is provided for storinginformation and instructions.

The communication interface 2050 enables the computer system 2000 tocommunicate over one or more networks 2080 (e.g., cellular network)through use of the network link (wireless or wired). Using the networklink, the computer system 2000 can communicate with one or morecomputing devices, one or more servers, and/or one or more AVs 102. Theexecutable instructions stored in the memory 2020 can include selectionand map constraint configuration instructions 2024, which enables thecomputer system 2000 to provide a map constraint interface and receiveinputs to amend autonomy map documents from a fleet operator. Theinstructions can further include map constraint deployment instructions2026 which enables the computer system 2000 to compress edited autonomymap documents into document images or snapshots and compiled fortransmission to AVs 102 for integration into existing autonomy maps.

The processor 2010 is configured with software and/or other logic toperform one or more processes, steps and other functions described withimplementations, such as described with respect to FIGS. 1-19, andelsewhere in the present application. Examples described herein arerelated to the use of the computer system 2000 for implementing thetechniques described herein. According to one example, those techniquesare performed by the computer system 2000 in response to the processor2010 executing one or more sequences of one or more instructionscontained in the main memory 2020. Such instructions may be read intothe main memory 2020 from another machine-readable medium, such as thestorage device 2040. Execution of the sequences of instructionscontained in the main memory 2020 causes the processor 2010 to performthe process steps described herein. In alternative implementations,hard-wired circuitry may be used in place of or in combination withsoftware instructions to implement examples described herein. Thus, theexamples described are not limited to any specific combination ofhardware circuitry and software.

It is contemplated for examples described herein to extend to individualelements and concepts described herein, independently of other concepts,ideas or systems, as well as for examples to include combinations ofelements recited anywhere in this application. Although examples aredescribed in detail herein with reference to the accompanying drawings,it is to be understood that the concepts are not limited to thoseprecise examples. As such, many modifications and variations will beapparent to practitioners skilled in this art. Accordingly, it isintended that the scope of the concepts be defined by the followingclaims and their equivalents. Furthermore, it is contemplated that aparticular feature described either individually or as part of anexample can be combined with other individually described features, orparts of other examples, even if the other features and examples make nomention of the particular feature. Thus, the absence of describingcombinations should not preclude claiming rights to such combinations.

The technology discussed herein makes reference to computing devices,databases, software applications, and other computer-based systems, aswell as actions taken and information sent to and from such systems. Oneof ordinary skill in the art will recognize that the inherentflexibility of computer-based systems allows for a great variety ofpossible configurations, combinations, and divisions of tasks andfunctionality between and among components. For instance, computerimplemented processes discussed herein can be implemented using a singlecomputing device or multiple computing devices working in combination.Databases and applications can be implemented on a single system ordistributed across multiple systems. Distributed components can operatesequentially or in parallel. Furthermore, computing tasks discussedherein as being performed at computing device(s) remote from the vehiclecan instead be performed at the vehicle (e.g., via the vehicle computingsystem), or vice versa. Such configurations can be implemented withoutdeviating from the scope of the present disclosure.

The various memories (i.e., 2020, 2030, and/or memory of the processorunit(s) 2010 and/or storage device 2040) may store one or more sets ofinstructions and data structures (e.g., instructions) 2024 and 2026embodying or used by any one or more of the methodologies or functionsdescribed herein. These instructions, when executed by processor unit(s)2010 cause various operations to implement the disclosed examples.

As used herein, the terms “machine-storage medium,” “device-storagemedium,” “computer-storage medium” (referred to collectively as“machine-storage medium”) mean the same thing and may be usedinterchangeably in this disclosure. The terms refer to a single ormultiple storage devices and/or media (e.g., a centralized ordistributed database, and/or associated caches and servers) that storeexecutable instructions and/or data, as well as cloud-based storagesystems or storage networks that include multiple storage apparatus ordevices. The terms shall accordingly be taken to include, but not belimited to, solid-state memories, and optical and magnetic media,including memory internal or external to processors. Specific examplesof machine-storage media, computer-storage media, and/or device-storagemedia include non-volatile memory, including by way of examplesemiconductor memory devices, e.g., erasable programmable read-onlymemory (EPROM), electrically erasable programmable read-only memory(EEPROM), FPGA, and flash memory devices; magnetic disks such asinternal hard disks and removable disks; magneto-optical disks; andCD-ROM and DVD-ROM disks. The terms machine-storage media,computer-storage media, and device-storage media specifically excludecarrier waves, modulated data signals, and other such media, at leastsome of which are covered under the term “signal medium” discussedbelow.

The term “signal medium” or “transmission medium” shall be taken toinclude any form of modulated data signal, carrier wave, and so forth.The term “modulated data signal” means a signal that has one or more ofits characteristics set or changed in such a matter as to encodeinformation in the signal.

The terms “machine-readable medium,” “computer-readable medium” and“device-readable medium” mean the same thing and may be usedinterchangeably in this disclosure. The terms are defined to includeboth machine-storage media and signal media. Thus, the terms includeboth storage devices/media and carrier waves/modulated data signals.

The instructions 2024 and 2026 can further be transmitted or receivedover a communications network 2080 using a transmission medium via thenetwork interface device 2050 using any one of a number of well-knowntransfer protocols (e.g., HTTP). Examples of communication networksinclude a LAN, a WAN, the Internet, mobile telephone networks, plain oldtelephone service (POTS) networks, and wireless data networks (e.g.,Wi-Fi, 3G, 4G LTE/LTE-A, 5G or WiMAX networks). The term “transmissionmedium” shall be taken to include any intangible medium that is capableof storing, encoding, or carrying instructions for execution by themachine, and includes digital or analog communications signals or otherintangible media to facilitate communication of such software.

Throughout this specification, plural instances may implementcomponents, operations, or structures described as a single instance.Although individual operations of one or more methods are illustratedand described as separate operations, one or more of the individualoperations may be performed concurrently, and nothing requires that theoperations be performed in the order illustrated. Structures andfunctionality presented as separate components in example configurationsmay be implemented as a combined structure or component. Similarly,structures and functionality presented as a single component may beimplemented as separate components. These and other variations,modifications, additions, and improvements fall within the scope of thesubject matter herein.

Various components are described in the present disclosure as beingconfigured in a particular way. A component may be configured in anysuitable manner. For example, a component that is or that includes acomputing device may be configured with suitable software instructionsthat program the computing device. A component may also be configured byvirtue of its hardware arrangement or in any other suitable manner.

To better illustrate the methods and apparatuses described herein, anon-limiting set of Example embodiments are set forth below asnumerically identified Examples.

Example 1 is a computer-implemented method of controlling navigation ofan autonomous vehicle, comprising accessing, by one or more processors,map data descriptive of the identity and location of different travelways within a surrounding environment of the autonomous vehicle;accessing, by the one or more processors, constraint data descriptive ofone or more geographic areas or geographic identifiers, within the mapdata, for which associated navigational constraints are defined, theconstraint data comprising a depart constraint that specifies an areathat an autonomous vehicle may not enter but may exit if inside the areawhen the depart constraint is imposed; determining, by the one or moreprocessors, a travel route for navigating the autonomous vehicle basedat least in part from the map data evaluated relative to the constraintdata including the depart constraint; and controlling, by the one ormore processors, motion of the autonomous vehicle based at least in parton the determined travel route.

Example 2 is a method as in Example 1, further comprising imposing thedepart constraint on a lane in the map data, the depart constraintindicating that an autonomous vehicle in the lane may continue totraverse the lane while inside the lane and may exit the lane but thatan autonomous vehicle outside of the lane may not enter the lane,whereby the lane is given a high traversal cost to bias an autonomousvehicle in the lane towards exiting the lane.

Example 3 is a method as in Examples 1 or 2, wherein the determinedtravel route comprises a plurality of travel way portions, each travelway portion defined by one or more of a travel way identifier, a startpoint, an end point, a directionality, or connectivity identifiers forother adjacent travel way portions.

Example 4 is a method as in any of Examples 1-3, wherein the one or moreprocessors receive one or more constraint files including the constraintdata from one or more remote computing devices configured to controloperation of a fleet of autonomous vehicles.

Example 5 is a method as in any of Examples 1-4, wherein each of the oneor more constraint files includes one or more polygons, each polygonhaving a boundary defined relative to a geographic area and anassociated application type.

Example 6 is a method as in any of Examples 1-5, wherein determining thetravel route for navigating the autonomous vehicle comprisesdetermining, by the one or more processors, permitted travel wayportions, the permitted travel way portions being described byconstraint data as (i) having a default permit state, (ii) beingcompletely enclosed by a complete inclusion polygon, or (iii) beingcompletely enclosed or partially touched by a partial inclusion polygon;determining, by the one or more processors, forbidden travel wayportions, the forbidden travel way portions being described by theconstraint data as (i) having a default forbid state, (ii) beingcompletely enclosed by a complete exclusion polygon, or (iii) beingcompletely enclosed or partially touched by a partial exclusion polygon;and evaluating, by the one or more processors, the map data to accountfor the permitted travel way portions and the forbidden travel wayportions.

Example 7 is a method as in any of Examples 1-6, further comprising theone or more remote computing devices generating a map constraintinterface enabling a fleet operator to update map constraints forautonomous vehicles (AVs), the map constraint interface enabling thefleet operator to configure a set of constraint layers of one or moreautonomy maps utilized by the AVs for navigation, each constraint layerin the set of constraint layers comprising a toggle feature that enablesthe fleet operator to activate and deactivate the constraint layer;receiving, via the map constraint interface, a set of inputs configuringthe set of constraint layers of the one or more autonomy maps; compilinga set of map constraints corresponding to the configured set ofconstraint layers into a document container; and outputting, via acommunication interface over one or more networks, the documentcontainer to a subset of the AVs to enable the subset of AVs tointegrate the set of map constraints with the one or more autonomy maps.

Example 8 is a computing system for controlling navigation of anautonomous vehicle, comprising one or more processors; and one or morememory devices, the one or more memory devices storing instructions thatwhen executed by the one or more processors cause the one or moreprocessors to perform operations, the operations comprising accessingmap data descriptive of the identity and location of different travelways within a surrounding environment of the autonomous vehicle;accessing constraint data descriptive of one or more geographic areas orgeographic identifiers, within the map data, for which associatednavigational constraints are defined, the constraint data comprising adepart constraint that specifies an area that an autonomous vehicle maynot enter but may exit if inside the area when the depart constraint isimposed; determining a travel route for navigating the autonomousvehicle based at least in part from the map data evaluated relative tothe constraint data including the depart constraint; and controllingmotion of the autonomous vehicle based at least in part on thedetermined travel route.

Example 9 is a computing system as in Example 8, wherein the one or morememory devices further stores instructions that when executed by the oneor more processors cause the one or more processors to impose the departconstraint on a lane in the map data, the depart constraint indicatingthat an autonomous vehicle in the lane may continue to traverse the lanewhile inside the lane and may exit the lane but that an autonomousvehicle outside of the lane may not enter the lane, whereby the lane isgiven a high traversal cost to bias an autonomous vehicle in the lanetowards exiting the lane.

Example 10 is a computing system as in Example 8 or 9, wherein thedetermined travel route comprises a plurality of travel way portions,each travel way portion defined by one or more of a travel wayidentifier, a start point, an end point, a directionality, orconnectivity identifiers for other adjacent travel way portions.

Example 11 is a computing system as in any of Examples 8-10, furthercomprising one or more remote computing devices configured to controloperation of a fleet of autonomous vehicles, the one or more remotecomputing devices providing one or more constraint files including theconstraint data to the one or more processors.

Example 12 is a computing system as in any of Examples 8-11, whereineach of the one or more constraint files includes one or more polygons,each polygon having a boundary defined relative to a geographic area andan associated application type.

Example 13 is a computing system as in any of Examples 8-12, wherein theone or more memory devices further store instructions that when executedby the one or more processors cause the one or more processors todetermine the travel route for navigating the autonomous vehicle bydetermining permitted travel way portions, the permitted travel wayportions being described by constraint data as (i) having a defaultpermit state, (ii) being completely enclosed by a complete inclusionpolygon, or (iii) being completely enclosed or partially touched by apartial inclusion polygon; determining forbidden travel way portions,the forbidden travel way portions being described by the constraint dataas (i) having a default forbid state, (ii) being completely enclosed bya complete exclusion polygon, or (iii) being completely enclosed orpartially touched by a partial exclusion polygon; and evaluating the mapdata to account for the permitted travel way portions and the forbiddentravel way portions.

Example 14 is a computing system as in any of Examples 8-13, wherein theone or more remote computing devices include instructions that whenexecuted by the one or more remote computing devices cause the one ormore remote computing devices to generate a map constraint interfaceenabling a fleet operator to update map constraints for autonomousvehicles (AVs), the map constraint interface enabling the fleet operatorto configure a set of constraint layers of one or more autonomy mapsutilized by the AVs for navigation, each constraint layer in the set ofconstraint layers comprising a toggle feature that enables the fleetoperator to activate and deactivate the constraint layer; receive, viathe map constraint interface, a set of inputs configuring the set ofconstraint layers of the one or more autonomy maps; compile a set of mapconstraints corresponding to the configured set of constraint layersinto a document container; and output, via a communication interfaceover one or more networks, the document container to a subset of the AVsto enable the subset of AVs to integrate the set of map constraints withthe one or more autonomy maps.

Example 15 is an autonomous vehicle, comprising one or morecommunication interfaces for wirelessly communicating with one or moreremote computing devices configured to control operation of a fleet ofautonomous vehicles; one or more processors; and one or morenon-transitory computer-readable media that collectively storeinstructions that, when executed by the one or more processors, causethe one or more processors to perform operations, the operationscomprising accessing map data descriptive of the identity and locationof different travel ways within a surrounding environment of theautonomous vehicle; accessing constraint data descriptive of one or moregeographic areas or geographic identifiers, within the map data, forwhich associated navigational constraints are defined, the constraintdata comprising a depart constraint that specifies an area that anautonomous vehicle may not enter but may exit if inside the area whenthe depart constraint is imposed; determining a travel route fornavigating the autonomous vehicle based at least in part from the mapdata evaluated relative to the constraint data including the departconstraint; and controlling motion of the autonomous vehicle based atleast in part on the determined travel route.

Example 16 is an autonomous vehicle as in Example 15, wherein the one ormore non-transitory computer-readable media further store instructionsthat when executed by the one or more processors cause the one or moreprocessors to impose the depart constraint on a lane in the map data,the depart constraint indicating that when the autonomous vehicle is inthe lane the autonomous vehicle may continue to traverse the lane whileinside the lane and may exit the lane but that when the autonomousvehicle is outside of the lane the autonomous vehicle may not enter thelane, whereby the lane is given a high traversal cost to bias theautonomous vehicle when in the lane towards exiting the lane.

Example 17 is an autonomous vehicle as in Examples 15 or 16, wherein thedetermined travel route comprises a plurality of travel way portions,each travel way portion defined by one or more of a travel wayidentifier, a start point, an end point, a directionality, orconnectivity identifiers for other adjacent travel way portions.

Example 18 is an autonomous vehicle as in any of Examples 15-17, whereinthe one or more communication interfaces receive from the one or moreremote computing devices one or more constraint files including theconstraint data.

Example 19 is an autonomous vehicle as in any of Examples 15-18, whereineach of the one or more constraint files includes one or more polygons,each polygon having a boundary defined relative to a geographic area andan associated application type.

Example 20 is an autonomous vehicle as in any of Examples 15-19, whereinthe one or more non-transitory computer-readable media further storeinstructions that when executed by the one or more processors cause theone or more processors to determine the travel route for navigating theautonomous vehicle by determining permitted travel way portions, thepermitted travel way portions being described by constraint data as (i)having a default permit state, (ii) being completely enclosed by acomplete inclusion polygon, or (iii) being completely enclosed orpartially touched by a partial inclusion polygon; determining forbiddentravel way portions, the forbidden travel way portions being describedby the constraint data as (i) having a default forbid state, (ii) beingcompletely enclosed by a complete exclusion polygon, or (iii) beingcompletely enclosed or partially touched by a partial exclusion polygon;and evaluating the map data to account for the permitted travel wayportions and the forbidden travel way portions.

Example 21 is an autonomous vehicle as in any of Examples 15-20, furthercomprising one or more autonomy maps, wherein the one or morecommunication interfaces receive from the one or more remote computingdevices the one or more constraint files including a set of mapconstraints in a document container, the map constraints beingintegrated with the one or more autonomy maps.

Example 22 is a computing device for controlling one or more autonomousvehicles, the computing device comprising one or more processors; and amemory storing instructions that, when executed by the one or moreprocessors, cause the one or more processors to receive, from one ormore networks, traffic flow constraint information from at least one ofa central planning resource or a traffic monitoring resource; based onthe traffic flow constraint information, update autonomy map constraintsfor autonomous vehicles operating in a given region, the autonomy mapincluding constraint data defining constraints descriptive of one ormore geographic areas or geographic identifiers for which associatednavigational constraints are defined, the constraint data comprising adepart constraint that specifies an area that an autonomous vehicle maynot enter but may exit if inside the area when the depart constraint isimposed; and transmit, over the one or more networks, data indicatingthe autonomy map constraints to the one or more autonomous vehicles.

Example 23 is a computing device as in Example 22, wherein the executedinstructions cause the one or more processors to generate a constraintfile comprising the constraint data and to transmit the constraint fileto the one or more autonomous vehicles.

Example 24 is a computing device as in Examples 22 or 23, wherein thetraffic flow constraint information identifies a planned event thatcorresponds to a road segment closure within the given region.

Example 25 is a computing device as in any of Examples 22-24, whereinthe planned event corresponds to at least one of road construction orutility servicing.

Example 26 is a computing device as in any of Examples 22-25, whereinthe planned event comprises at least one of a protest, a parade, asporting event, and a festival.

Example 27 is a computing device as in any of Examples 22-26, whereintraffic flow constraint information is received from a live,crowded-sourced traffic resource.

Example 28 is a computing device as in any of Examples 22-27, whereinthe one or more processors selectively transmit the data indicating theautonomy map constraints to the one or more autonomous vehicles based onthe one or more autonomous vehicles each being on a current routeconverging towards or intersecting with a road segment closure definedby the autonomy map constraints.

Example 29 is a non-transitory computer-readable medium storinginstructions that, when executed by one or more processors, cause theone or more processors to control navigation of an autonomous vehicle byaccessing map data descriptive of the identity and location of differenttravel ways within a surrounding environment of the autonomous vehicle;accessing constraint data descriptive of one or more geographic areas orgeographic identifiers, within the map data, for which associatednavigational constraints are defined, the constraint data comprising adepart constraint that specifies an area that an autonomous vehicle maynot enter but may exit if inside the area when the depart constraint isimposed; determining a travel route for navigating the autonomousvehicle based at least in part from the map data evaluated relative tothe constraint data including the depart constraint; and controllingmotion of the autonomous vehicle based at least in part on thedetermined travel route.

Example 30 is a medium as in Example 29, further comprising instructionsthat, when executed by one or more processors, cause the one or moreprocessors to impose the depart constraint on a lane in the map data,the depart constraint indicating that an autonomous vehicle in the lanemay continue to traverse the lane while inside the lane and may exit thelane but that an autonomous vehicle outside of the lane may not enterthe lane, whereby the lane is given a high traversal cost to bias anautonomous vehicle in the lane towards exiting the lane.

Example 31 is a medium as in Examples 29 or 30, wherein the determinedtravel route comprises a plurality of travel way portions, each travelway portion defined by one or more of a travel way identifier, a startpoint, an end point, a directionality, or connectivity identifiers forother adjacent travel way portions.

Example 32 is a medium as in any of Examples 29-31, further comprisinginstructions that, when executed by the one or more processors, causethe one or more processors to receive one or more constraint filesincluding the constraint data from one or more remote computing devicesconfigured to control operation of a fleet of autonomous vehicles.

Example 33 is a medium as in any of Examples 29-32, wherein each of theone or more constraint files includes one or more polygons, each polygonhaving a boundary defined relative to a geographic area and anassociated application type.

Example 34 is a medium as in any of Examples 29-33, wherein instructionsfor determining the travel route for navigating the autonomous vehiclefurther comprises instructions that, when executed by the one or moreprocessors, cause the one or more processors to determine permittedtravel way portions, the permitted travel way portions being describedby constraint data as (i) having a default permit state, (ii) beingcompletely enclosed by a complete inclusion polygon, or (iii) beingcompletely enclosed or partially touched by a partial inclusion polygon;determine forbidden travel way portions, the forbidden travel wayportions being described by the constraint data as (i) having a defaultforbid state, (ii) being completely enclosed by a complete exclusionpolygon, or (iii) being completely enclosed or partially touched by apartial exclusion polygon; and evaluate the map data to account for thepermitted travel way portions and the forbidden travel way portions.

Example 35 is a non-transitory computer-readable medium storinginstructions that, when executed by one or more processors, cause theone or more processors to control one or more autonomous vehicles byreceiving, from one or more networks, traffic flow constraintinformation from at least one of a central planning resource or atraffic monitoring resource; based on the traffic flow constraintinformation, updating autonomy map constraints for autonomous vehiclesoperating in a given region, the autonomy map including constraint datadefining constraints descriptive of one or more geographic areas orgeographic identifiers for which associated navigational constraints aredefined, the constraint data comprising a depart constraint thatspecifies an area that an autonomous vehicle may not enter but may exitif inside the area when the depart constraint is imposed; andtransmitting, over the one or more networks, data indicating theautonomy map constraints to the one or more autonomous vehicles.

Example 36 is a medium as in Example 35, further comprising instructionsthat, when executed by the one or more processors, cause the one or moreprocessors to generate a constraint file comprising the constraint dataand to transmit the constraint file to the one or more autonomousvehicles.

Example 37 is a medium as in Examples 35 or 36, wherein the traffic flowconstraint information identifies a planned event that corresponds to aroad segment closure within the given region.

Example 38 is a medium as in any of Examples 35-37, wherein the plannedevent corresponds to at least one of road construction or utilityservicing.

Example 39 is a medium as in any of Examples 35-38, wherein the plannedevent comprises at least one of a protest, a parade, a sporting event,and a festival.

Example 40 is a medium as in any of Examples 35-39, wherein traffic flowconstraint information is received from a live, crowded-sourced trafficresource.

Example 41 is a medium as in any of Examples 35-40, further comprisinginstructions that, when executed by the one or more processors, causethe one or more processors to selectively transmit the data indicatingthe autonomy map constraints to the one or more autonomous vehiclesbased on the one or more autonomous vehicles each being on a currentroute converging towards or intersecting with a road segment closuredefined by the autonomy map constraints.

The above description is intended to be illustrative, and notrestrictive. For example, the above-described examples (or one or moreaspects thereof) can be used in combination with others. Other examplescan be used, such as by one of ordinary skill in the art upon reviewingthe above description. The Abstract is to allow the reader to quicklyascertain the nature of the technical disclosure, for example, to complywith 37 C.F.R. § 1.72(b) in the United States of America. It issubmitted with the understanding that it will not be used to interpretor limit the scope or meaning of the claims.

Also, in the above Detailed Description, various features can be groupedtogether to streamline the disclosure. However, the claims cannot setforth every feature disclosed herein, as examples can feature a subsetof such features. Further, examples can include fewer features thanthose disclosed in a particular example. Thus, the following claims arehereby incorporated into the Detailed Description, with each claimstanding on its own as a separate example. The scope of the examplesdisclosed herein is to be determined with reference to the appendedclaims, along with the full scope of equivalents to which such claimsare entitled.

While the present subject matter has been described in detail withrespect to specific example embodiments and methods thereof, it will beappreciated that those skilled in the art, upon attaining anunderstanding of the foregoing can readily produce alterations to,variations of, and equivalents to such embodiments. Accordingly, thescope of the present disclosure is by way of example rather than by wayof limitation, and the subject disclosure does not preclude inclusion ofsuch modifications, variations and/or additions to the present subjectmatter as would be readily apparent to one of ordinary skill in the art.

1. A computer-implemented method of controlling navigation of anautonomous vehicle, comprising: accessing event data describing an eventat a location in a geographic area; determining a geographic identifierdescribing the location; generating constraint data using the geographicidentifier and the event data, the constraint data describing a departconstraint associated with the location, the depart constraintindicating that an autonomous vehicle is permitted to enter the locationonly from other locations that are also associated with a departconstraint; determining a travel route for navigating the autonomousvehicle using map data evaluated relative to the constraint data; andinstructing the autonomous vehicle to travel along the determined travelroute.
 2. The computer-implemented method of claim 1, wherein the departconstraint also indicates that an autonomous vehicle in the location maycontinue to travel within the location and may exit the location butthat an autonomous vehicle outside of the location may not enter thelocation.
 3. The computer-implemented method of claim 2, furthercomprising modifying a traversal cost of a first travel way portion inthe location, the modifying being based at least in part on the departconstraint.
 4. The computer-implemented method of claim 1, furthercomprising controlling motion of the autonomous vehicle based at leastin part on the determined travel route.
 5. The computer-implementedmethod of claim 1, the constraint data describing a polygon indicating aboundary of the location.
 6. The computer-implemented method of claim 1,further comprising: using the constraint data, determining a set ofpermitted travel way portions from a plurality of travel way portions inthe location; and determining a set of forbidden travel way portionsfrom the plurality of travel way portions in the location using theconstraint data, the determining of the travel route being based on theset of permitted travel way portions and the set of forbidden travel wayportions.
 7. The computer-implemented method of claim 6, the set ofpermitted travel way portions being described by the constraint data asat least one of having a default permit state, being enclosed by acomplete inclusion polygon, or being touched by a partial inclusionpolygon.
 8. The computer-implemented method of claim 6, the set offorbidden travel way portions being described by the constraint data asat least one of having a default forbid state, being enclosed by acomplete exclusion polygon, or being touched by a partial exclusionpolygon.
 9. The computer-implemented method of claim 1, furthercomprising: generating a map constraint interface, the map constraintinterface to receive updates to the constraint data; receiving, via themap constraint interface, an update to the constraint data; and sendingupdated constraint data to at least one AV.
 10. The computer-implementedmethod of claim 9, the map constraint interface comprising a set ofconstraint layer input fields associated with the map data, the set ofconstraint layer input fields to toggle activation of the respectiveconstraint layers.
 11. The computer-implemented method of claim 1,further comprising determining a set of constraint layers that areactive for the map data, the determining of the travel route based on aportion of the set of constraint layers that are active for the mapdata.
 12. A computing system for controlling navigation of an autonomousvehicle, the computing system comprising: at least one processor; and atleast one memory device comprising instructions stored thereon that,when executed by the at least one processor, cause the at least oneprocessor to perform operations comprising: accessing event datadescribing an event at a location in a geographic area; determining ageographic identifier describing the location; generating constraintdata using the geographic identifier and the event data, the constraintdata describing a depart constraint associated with the location, thedepart constraint indicating that an autonomous vehicle is permitted toenter location only from other locations that are also associated with adepart constraint; determining a travel route for navigating theautonomous vehicle using map data evaluated relative to the constraintdata; and instructing the autonomous vehicle to travel along thedetermined travel route.
 13. The computing system of claim 12, whereinthe depart constraint also indicates that an autonomous vehicle in thelocation may continue to travel within the location and may exit thelocation but that an autonomous vehicle outside of the location may notenter the location.
 14. The computing system of claim 13, the operationsfurther comprising modifying a traversal cost of a first travel wayportion in the location, the modifying being based at least in part onthe depart constraint.
 15. The computing system of claim 12, theoperations further comprising controlling motion of the autonomousvehicle based at least in part on the determined travel route.
 16. Thecomputing system of claim 12, the constraint data describing a polygonindicating a boundary of the location.
 17. The computing system of claim12, the operations further comprising: using the constraint data,determining a set of permitted travel way portions from a plurality oftravel way portions in the location; and determining a set of forbiddentravel way portions from the plurality of travel way portions in thelocation using the constraint data, the determining of the travel routebeing based on the set of permitted travel way portions and the set offorbidden travel way portions.
 18. The computing system of claim 17, theset of permitted travel way portions being described by the constraintdata as at least one of having a default permit state, being enclosed bya complete inclusion polygon, or being touched by a partial inclusionpolygon.
 19. The computing system of claim 17, the set of forbiddentravel way portions being described by the constraint data as at leastone of having a default forbid state, being enclosed by a completeexclusion polygon, or being touched by a partial exclusion polygon. 20.A non-transitory computer-readable medium comprising instructionsthereon that, when executed by at least one processor, causes the atleast one processor to perform operations comprising: accessing eventdata describing an event at a location in a geographic area; determininga geographic identifier describing the location; generating constraintdata using the geographic identifier and the event data, the constraintdata describing a depart constraint associated with the location, thedepart constraint indicating that an autonomous vehicle is permitted toenter location only from other locations that are also associated with adepart constraint; determining a travel route for navigating theautonomous vehicle using map data evaluated relative to the constraintdata; and instructing the autonomous vehicle to travel along thedetermined travel route.